Didier Raboud <o...@debian.org> wrote on 07/10/2022 at 15:24:23+0200:
> (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!) > > So. We should be having a public discussion about our per-source ownership, > _and_ about spread responsibilities. A long-established specificity of > Debian > development is that we have had only one, super-powerful, authorization > scheme to the archive: become an uploading DD and get unrestricted, > unsupervised upload right upon all packages. We solved the social friction > using processes, documentation, etc. (Yes, DM status opened restricted upload > rights to limited package sets). There are two sides to that. > > As all uploading DDs _can_ upload, we get (theoretical) built-in failover: > when one goes emeritus (the ideal case), they can be replaced by any other > without much process. We also get low-cost emergency fixups; if I upload > something broken just before going (explicitly) VAC, anyone can revert and > upload. Not having explicit barriers in place is (was?) a nice way to reduce > administrativia, and to address ownership disputes in the open; the only > restrictions on NMUs, orphaning and package salvaging, etc, are social, not > technical. And by the nature of being social, we address them with > processes, > documentation, policy (and committees enforcing some of the rules). In other > words, no technical barriers prevent me from uploading a broken > src:base-files; > but I will face social backlash (and possibly administrative measures), > because I would have broken agreed-upon social norms. > > The flip-side of this is also that we all _care_; as I _can_ upload src:base- > files, I feel partly responsible for it. I argue that uploading DDs care > about > all of Debian packages, not only because they care about Debian, but also > because they have the needed authorization (power) to fix any and all of > them. > What matters is not that the power is exercised, but that it exists. The set > "all Debian source packages" is a concern for all of us; we're one large team > for one _very_ large set. Attempts to split this set has worked by interest- > groups so far; language-specific, desktop-environment-specific, etc. (And it > has worked quite well for these groups, also because the subsets they care > about are reasonably self-contained). But as we all care, we are also all > entitled to opinions (that might be conflicting) about OS-level design > decisions which (as was amply demonstrated by this mega-thread) cannot > reasonably be addressed by source-level ownership. Deciding that /lib is > going > to be a symlink cannot (and, for the avoidance of doubt, has not) be a single > source package maintainer(s)' decision. But as things currently work, it > ends > up being implemented and steered as such, with our source-package-level > conflict-handling processes (TC, etc, etc). > > So, we have eachothers' backs, and we all care, how to move from there? > > 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. I can understand your train of thoughts, but to be honest with myself, I'd rather keep the social limitation rather than enforce a technical limitation that would prevent me to upload any package and force me to do $process and wait for someone else's being available to validate it and give me access. I really think it's not the matter, to me the matter is package ownership. While new contributors should feel that it's mandatory to discuss with maintainers, having people clamped so tightly to their packages that you don't know if these are actually packages or src:THE_ring is the issue to me. Cheers! :) -- PEB
signature.asc
Description: PGP signature
