(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.
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?
Best,
OdyX
P.S. I'll be away from Debian lists next week, so don't take absence of
response for disdain!
P.S.2. Sorry if I mixed "DD" with "uploading DDs"; as we're talking source
packages, it probably went easier without specifying it everytime. Non-
uploading DD, know that your work and opinion is valued and respected!
