(Sorry for the delay in getting back to that thread. #life) What most respondents have gotten across as the bulk of my proposal seems to be: "we could limit upload rights to certain packages"
... where what I was trying to get across was: "we could team-maintain the core of Debian (and by extension, other subsets)" The problem I'm trying to describe (and therefore the mitigations/solutions I put up for discussion) is that source package realms are not the right granularity for Debian development anymore. Quoting zack from a nice message on d-private (with his permission): At a certain time in Octobre 2022, Stefano Zacchiroli wrote : > The granularity of the package is no longer compatible with our modern > collaborative software development works. And Debian implement a > particularly strong version of it, which goes against the (now decades > old, coming from the early agile days) software engineering wisdom that > "strong code ownership" is bad for an engineering team. Many attempts > have been made over time to mitigate this problem (e.g., team > maintenance of group of interrelated packages, low threshold NMU, making > NMUs more socially acceptable, etc.). But they are just that: > mitigations, not actual solutions. > > Debian needs to get away from packages as unit of responsibility (...) From that discussion starting point, I unrolled two thought threads: a) how to lower the walls of our source package castles; b) topic teams (ala Ubuntu). From what I read, only a) got serious discussion. I particularly like Russ' take, which I understand as follows: it'd be nice if it were easy to have smaller upload scope, _provided that_ there were an easy way to get upload rights back. Something like "DDs can grant themselves upload rights to certain packages, with our without expiration; they can review and revoke these rights anytime. They can also get archive-wide upload rights, but this has an quite short expiration." The latter part would be to allow BSPs, or archive-wide upload batches, but not (necessarily?) allow DDs to get constant archive-wide upload rights. But but but... I think it would improve Debian's security to do that; but it doesn't really address any of the problems I was trying to address. :-) Le vendredi, 7 octobre 2022, 15.24:23 h CEST Didier Raboud a écrit : > Looking at how Ubuntu is structured (with topic teams) made me wonder if > some variation of that couldn't reasonably be applied to Debian, by > dividing our giant set in subsets (topic teams, baskets, ...), under > clearer team's responsibilities, and onboarding processes. Le vendredi, 7 octobre 2022, 15.24:23 h CEST Didier Raboud a écrit : > In the current situation in which there's quite some friction around > "merged- usr/" (and in the lingering situation around init systems), I'd > see a "Debian core" subset made of base-files, libc, authority over the > filesystem layout, dpkg, apt; and a "Debian system core" subset with > authority over supported and default init systems, kernel, initramfs, > firmware*. Specifically, this is something I'd like to discuss in more extensive terms. I think I'm postulating that Debian would be in a better place with a "Debian core" topic team, in charge of certain "base source packages", but _ALSO_ of core Debian decisions: filesystem layout, default init systems, etc; all these things which responsibility is _not_ clearly within a specific source package's realm. (disclaimer: I'm well aware of the social friction implied from moving towards such a situation. People change, their interests and viewpoints also do; folks join and leave Debian. We should be able to discuss such setups in the abstract; without diving in "implementation details" (sic).) Thoughts? OdyX
signature.asc
Description: This is a digitally signed message part.
