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 ;-)
Le 13/03/2024 à 01:35, Vaclav Petras via grass-dev a écrit :
On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek <pesej.ond...@gmail.com> 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?
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.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
