Hi, Quoting Didier Raboud (2022-10-07 15:24:23) > (This is the continuation of an unspecified thread in the debian-private list > that generated enough positive content that I deemed it smart enough to jump > off from it, to a public mailing list. I'm not quoting anything from anyone, > but there's certainly inspiration from various participants, so thanks for > that!)
I have read the thread on debian-private that you are probably referring to (the "hegemony" thread, right?), but... > 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. That would imply that certain > people would have more power: the "PostgreSQL server" subset team would have > authority and (technical) upload rights upon their packages. And others would > have less power: not being able to upload these anymore. The flip-side of > such a setup, in which a large set of uploading-DDs would see their power > over the "PostgresSQL server" set largely reduced, is that they would also > "care less" (why investigating an RC bug if I can't NMU anyway). FWIW, I'd > happily limit my uploading rights to forbid me to upload a Gnome package, a > kernel package, or a PostgreSQL package, provided that there would be > documented onboarding processes, should that ever interest me. > > But I argue that we're already _socially_ in such an environment: all > contributors (including uploading DDs) not already in any given team go > through onboarding processes, Salsa MRs' reviews, vetting and review before > they do upload directly (modulo NMUs, of course). It's just not enforced by > the archive. > > The last aspect would also be to completely remove the source-package-level > realms; within a subset, there would be no package-specific maintainers or > vetoes; disputes would move "out" from source-package-level to subset-level. > That's not to say that within-subset disputes wouldn't happen nor could be > escalated; it's rather to stipulate that the realms' boundaries wouldn't be > the source-packages', but the subset's. > > 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*. > > Was I rumbling in my bubble, or does any of this make sense? I do not think that what you are proposing solves the problems that were identified in that thread. I think the problem that was identified was, that it is currently in the power of individual maintainers have too much power over the packages they maintain. Thus, it is for example possible, that maintainers block contributions (with patches) of others. I think many in the thread concluded that maintaining a distribution is a team effort and requires the contributions and cooperation of many and that source packages cannot be seen as an entity that can be looked at in isolation. If I understand what you write correctly, then you propose to put into place a technical barrier for uploading other people's packages. But that will not reduce the ownership (or hegemony) of developers over their packages and thus not address the problems that were identified. Am I misunderstanding what you are proposing? Thanks! cheers, josch
signature.asc
Description: signature
