Re: [GRASS-dev] GRASS Teams on GitHub
Hi there, st 13. 3. 2024 v 1:36 odesílatel Vaclav Petras napsal: > On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek wrote: >> @Vaclav: Do you have some more points against the master-children >> schema? It seems that the general agreement is *for* the restructuring >> into parent and children teams. So far the only point against was "I >> didn't find team nesting particularly useful and we already had a >> couple of top-level teams." > > > ...and I didn't see it working for GDAL with people both in the parent team > and child teams and repos being assigned to both levels. > > How do you suggest we do it? Empty parent team without repos? Would that look > good? According to [1], all the child teams inherit the rights of their parents. Therefore, I guess that having one empty parent with no rights is okay and the correct way (also, you can see all children members there, so it does not "look" empty even if it does not have any member). Then we could go one of the two ways: * Having all the current teams as child teams of the master team * Having it more structured (grass-addons, grass, grass-website/promo) I prefer the second way (some rights could then be propagated, I guess) but would appreciate even the first one as it would clean up the overview a lot. >> Although I appreciate all the work you >> dedicate to the GitHub management, I don't think that this is a valid >> point against when compared to the positive ones (although it's >> understandable that nobody wants to drop something that they have just >> created). > Thanks. It is more that before it was a high priority for me to get access > rights in order (access rights to individuals both directly and through > teams, inactive people from 2000s and early 2010s grandfathered into GitHub > write access, ...). These parent-child teams are low priority compared to > that. Okay, thanks for the explanation. I see the reasoning behind the drop of the priority and cannot disagree - nobody even seemed to notice that before. I agree that there are many more important things to do. Although I still think it would help the situation in the github teams. st 13. 3. 2024 v 1:57 odesílatel Even Rouault napsal: > FYI I see this thread referencing the GDAL github team organization. As far > as I know, nobody has "designed" it with deep thoughts. It has the current > structure most likely as an accident of history... If I were to design it, I > would keep it simple and stupid. With git workflows, the concept of > "committer" as in SVN era is kinda irrelevant. You just need a sufficient > number of people with appropriate push rights to merge the flow of incoming > PRs, but if you have more than 10 people with push rights in a single repo, > that is already quite big. My 2 cents, and running away as I've no idea how > the GRASS team works ;-) Thanks for the insight, Even. It seems that I am very much on the side of the accidental structure :-). [1] https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams#nested-teams ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS Teams on GitHub
Hi again, Sorry to start revive the conversation from the silence but I have the feeling that it would be good to reach some consensus before we should let it rest. @Vaclav: Do you have some more points against the master-children schema? It seems that the general agreement is *for* the restructuring into parent and children teams. So far the only point against was "I didn't find team nesting particularly useful and we already had a couple of top-level teams." Although I appreciate all the work you dedicate to the GitHub management, I don't think that this is a valid point against when compared to the positive ones (although it's understandable that nobody wants to drop something that they have just created). Cheers from the discussion underworld, Ondrej čt 22. 2. 2024 v 9:35 odesílatel Ondřej Pešek napsal: > > Sweet devs, > > Looking at the GitHub teams within the OSGeo organisation [1], it is > impossible not to notice the fact that the GRASS people are very good > in making themselves visible through visual weed infestation. On one > side, it is nice to see GRASS all over the dance floor; on the other > one, I don't find it particularly polite to storm the org and see that > GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in > total). > > Wouldn't it be better to follow the example of GDAL instead? Creating > only one master team (grass) and then 11 child teams (grass-write, > grass-addons-write, ...)? It would make the org team overview much > cleaner. Also, you could see all grass child teams' members in one > place. > > In the name of New GitHub Order, > Ondrej > > PS: I also believe that we should reduce the number of GRASS teams and > consolidate some (grass-addons-subversion-committers -> > grass-addons-write) but I guess this is for another and much more > contentious discussion. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS Teams on GitHub
Hi Vaclav, Huidae, I was afraid of a long discussion (I know that the teams were changed recently and expected the consolidation to need more talks) and that's why I wanted to split it into two different threads: 1) master team and child teams, 2) necessity of all the teams we have. But whatever, let's then continue in both. Before inline comments, let me say that I understand that we somehow feel a "need" to have more teams than the other. I have never been against that, only mentioning that maybe we don't need such a vast number and that the master team would make it look nicer. čt 22. 2. 2024 v 22:20 odesílatel Vaclav Petras napsal: > If we say we want to cut down the number of teams, we can remove one or more > of the following: 1 or 2 Subversion teams (legacy, but both are in use now), > homebrew-docker team (complete legacy), grass-addons-write (could be merged > with grass-write depending on how much it will be used, it has one person who > is not in grass-write), grass-promo-write (can be merged with > grass-website-write depending on in which way the grass-promo repo will be > used). I would vote for getting rid of the legacy teams. I believe that the subversion team members could be consolidated into grass-write and grass-addons-write. I don't see any added value of the subversion ones except for flexing with "I've been here before you". I don't have anything against keeping those two separate as I see a difference in the repo's nature - the fact that the users are almost the same is just a current state and could change in the future. I don't have a strong opinion on the need of extra grass-promo-write. If you think it could be merged with grass-website-write, cool with me but I see some meaning there (as you answered to Huidae, "We may trust someone to manage a collection of materials in grass-promo, but we may want higher scrutiny for the grass-website repo which goes live after PR is merged") > We are not yet making use of the Maintain team (1 extra team). Is there a plan for what it will be used? The members are the same as of grass-admin. Is its purpose so different from the one of the admin team? > On Thu, 22 Feb 2024 at 14:51, Huidae Cho via grass-dev > wrote: >> >> Ondrej, >> >> I agree with you that there are too many teams for GRASS [1] and they should >> be consolidated (or not, but at least moved) as child teams. >> >> Do we still need these subversion teams? >> * grass-subversion-committers GRASS GIS Subversion committers >> * grass-addons-subversion-committers GRASS GIS Addons Subversion committers > > > These are people who had access in the Subversion times. We want these past > Subversion-time contributors to have Triage rights (whatever that means). The > grass-addons repo works differently, so the Subversion-time group has Write > access there, but that can be changed in the future easily as this group from > pre-GitHub times is separate from the active group in grass-addons-write. Isn't there grass-triage group for those whom we want to have Triage rights? >> I think we need this team. >> * grass-docker-homebrew-users Users for automated dockerhub and homebrew >> builds > > > I don't know why we have that. It works for notifications, but I haven't seen > that used. Another potential candidate for disintegration then? >> On Thu, Feb 22, 2024 at 1:35 AM Ondřej Pešek via grass-dev >> wrote: >>> Looking at the GitHub teams within the OSGeo organisation [1], it is >>> impossible not to notice the fact that the GRASS people are very good >>> in making themselves visible through visual weed infestation. On one >>> side, it is nice to see GRASS all over the dance floor; on the other >>> one, I don't find it particularly polite to storm the org and see that >>> GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in >>> total). > > Is that a practical problem for anyone? Not being a practical problem does not mean it cannot be done in a better way. >>> >>> Creating >>> only one master team (grass) and then 11 child teams (grass-write, >>> grass-addons-write, ...)? It would make the org team overview much >>> cleaner. > > Seeing how GDAL handles that, I didn't find team nesting particularly useful > and we already had a couple of top-level teams. > >>> >>> Also, you could see all grass child teams' members in one >>> place. > > That is still the only advantage I see, but then again, we already had > several teams and I created the new ones on the same level. I meant one master team not several ones. I personally do find a structured way of storing information useful (more than in an unstructured way).
[GRASS-dev] GRASS Teams on GitHub
Sweet devs, Looking at the GitHub teams within the OSGeo organisation [1], it is impossible not to notice the fact that the GRASS people are very good in making themselves visible through visual weed infestation. On one side, it is nice to see GRASS all over the dance floor; on the other one, I don't find it particularly polite to storm the org and see that GRASS owns 11 OSGEO's teams out of 24 in the overview (11 out of 26 in total). Wouldn't it be better to follow the example of GDAL instead? Creating only one master team (grass) and then 11 child teams (grass-write, grass-addons-write, ...)? It would make the org team overview much cleaner. Also, you could see all grass child teams' members in one place. In the name of New GitHub Order, Ondrej PS: I also believe that we should reduce the number of GRASS teams and consolidate some (grass-addons-subversion-committers -> grass-addons-write) but I guess this is for another and much more contentious discussion. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1
so 30. 9. 2023 v 16:12 odesílatel Markus Neteler via grass-dev napsal: > As far as I see the git on Windows issue has been solved as well as > many wxGUI bugs. > Still a few to go which are under review. Shall we wait for them? > Please let me know. Not only Windows wxGUI issues. It is impossible to change the layout from single window to the original one. I am using the original one with students, meaning that I am still using 8.2.x with them. Releasing 8.3.1 (where it is fixed) would let me to use 8.3.x versions with them without forcing them to compile it on their own. (the 8.3.0-broken r.watershed is also used there) So a new release would be appreciated also at my side. But that's just my two cents. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
