Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • Help Desk Help Desk
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 318
    • Issues 318
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication: https://www.eclipse.org/lists/eclipse.org-committers/msg01356.html

  • Eclipse FoundationEclipse Foundation
  • Help DeskHelp Desk
  • Issues
  • #42
Closed
Open
Issue created Apr 22, 2021 by Wayne Beaton@wbeatonReporter

Consider supporting arbitrary nesting of groups

For consideration...

As I understand it, GitLab supports arbitrarily nested groups.

Our standard practice is allocate resources "flat", independent of project structure. My observation is that with GitLub, "flat" means that we're creating a group for each project under the "eclipse" group, e.g., "/eclipse/dash", and all repositories associated with the corresponding project are created in that group.

We adopted the "flat" notion quite some time ago to mitigate the amount of work and negative effects of having to move resources following project restructuring (e.g., when projects move from one TLP to another).

That GitLab provides support for arbitrary nesting of groups, sets up automatic redirects for moved repositories, and otherwise provides what I assume are reasonably good management tools, presents an opportunity to reconsider the policy.

I'm thinking that a default position is to have a distinct group for each project to mitigate the risk of confusion regarding which project owns which repository (and by extension which developer has commit rights on which repository), but allow that project groups can themselves be arbitrarily organized into groups.

From the @webmaster workload perspective, I believe that we'll have to manage expectations that the webmaster will not be able to continuously tweak and move groups around.

Would allowing arbitrary nesting introduce significant work in the provisioning process? Are there scenarios that are particularly onerous?

For one, at very least, keeping track of arbitrary nesting and what goes where will require some additional thought/management/tracking.

@cguindon are permissions assigned at the group level or the repository level? Does the script that manages committer and project leads care about the group nesting?

Assignee
Assign to
Time tracking

Copyright © Eclipse Foundation, Inc. All Rights Reserved.     Privacy Policy | Terms of Use | Copyright Agent