On 2023-03-08, Maxim Cournoyer wrote: > On a side note, it would also introduce some kind of hierarchy in the > group, which I dislike. One of the things that make Guix special is > that it's pretty flat -- everybody can participate at the same level, at > least between committers). I'd rather we don't try to emulate Debian on > that point.
I have been watching this thread with great curiosity for exactly this reason! One of the things I like about Guix, coming from a couple decades of involvement with Debian, is the lack of package "ownership" ... in Debian, any Debian Developer with upload rights can technically upload any package, but it is considered inappropriate to do so without following various processes. Over the years, ways to opt-in to streamlined processes now exist, but the norm is still very much package "ownership". Guix is starting from a much more flexible model, but struggling with challenges of scale ... a small number of people maintaining a huge number of packages. I am a bit concerned that formalizing this much process for teams just yet... There is not much granularity of team scope and responsibilities. The current teams implementation seems to involve claiming one or more gnu/packages/*.scm files (or other files)... but not individual packages or groups of packages within one of those. It seems quite rough around the edges and I am concerned about how it will play out to further formalize the process. I almost wonder if it wouldn't be good to spell out what exactly is desired to be accomplished by having teams? Maybe much of that conversation has already happened, but ... spelling it out first, and then trying to come up with implementation details that attempt to fit the goals? I have a hunch that this dish might benefit from a bit more seasoning. I am not sure exactly which herbs and spices to reach for, or how long to leave it simmering on the stove... but I know people are getting hungry! live well, vagrant
signature.asc
Description: PGP signature
