Community
Participate
Working Groups
There are 3 possibilities right now: 1) Have one github organization for whole Eclipse TLP 2) Have one github organization per subproject - PDE, Platform, Equinox, JDT e.g https://github.com/eclipse-m2e/ 3) Use overall eclipse one https://github.com/eclipse/ I'm in favor of 2) as it will keep some separation and give some more visibility to subprojects. Also it will give some more resources if at any point we decide to use github actions for something.
PMC members please vote here so we have the decision written and we can proceed.
I prefer 1.) or 3.) Reason: the separation of the different sub-projects is IMHO outdated given the small number of people working on it. So at least the org structure should not emphasize the separation.
Given that organization controls committer rights. My vote is towards 2. Please correct me if my assumption is wrong
> Also it will give some more resources if at any point we decide to use github actions for something. Thanks an important point (Alex reminded me about that via a chat). I change my vote to option 2.)
(In reply to Lars Vogel from comment #2) > I prefer 1.) or 3.) > > Reason: the separation of the different sub-projects is IMHO outdated given > the small number of people working on it. So at least the org structure > should not emphasize the separation. See 577322 comment 2: we should clarify that having one organization for entire TLP still allows to manage commit rights per repository. I know that that should be possible in github (we have that in https://github.com/spotbugs) but who knows what & how is planned to be for Eclipse TLP organization. If that "commit rights per repo" is given, even if I'm not a PMC member, I would vote for 1) - have one organization for Eclipse TLP. I would be also fine with 2) but not with 3). The 3) is "overcrowded" and is not focused on IDE/SDK/TLP.
We do build from 25 repositories across all 4 sub projects for our daily builds. platform 14 pde 2 jdt 5 equinox 4 there are 2 more repositories common across all sub-projects(images and news) and 1 more for releng (for releng build tools). I feel it will be easy to manage committer rights with sub organizations rather than a single one with "commit rights per repo".
Github teams can control commit rights to individual repos under the same organization. So there is no issue there for controlling commit rights. With that said I prefer option 2) one org per subproject. It creates less of a mess of repos when going to an individual organization. I also want to consider what we may want to do with merging some repositories. For example, I want to merge equinox framework/bundles into one repo, with the name simply being 'equinox'. So that would be: https://github.com/eclipse-equinox/equinox https://github.com/eclipse-equinox/p2 https://github.com/eclipse-equinox/binaries Having 4 separate orgs allows our repos to be simple names without qualification. Option 1) is my close second choice. It is attractive because it means less management at the organization level. With all our repos being public I am not sure having separate orgs gains us more power with github actions. I think it would if we had private repos. Option 3) is a -1 for me. I don't want to added to the long list of 450+ repos already there. It gives us the least amount of cohesiveness as a project in my opinion.
I am inclined towards option 2. That said I have a question: If we go with 2, can we expect some level of customization in terms of policy making with sub orgs?
PMC discussed at today's call and decided to go with option 2: One organization per subproject.
