The last aspect would also be to completely remove the source-package-levelrealms; within a subset, there would be no package-specific maintainers or vetoes; disputes would move "out" from source-package-level to subset-level.
Didier Raboud wrote:
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.
Uhm. This makes me wonder what the real goal of this proposal is.
Is it about restricting the ability of DDs to upload any package
(something that has never really caused any real issues so far as I'm
aware)? Or is it really about having a way to work around
uncollaborative maintainers of specific packages?
If it's the latter, I'm afraid it could have more negative effects
than positive. While "package-specific maintainership" does have its >problems, it is essentially what has been keeping Debian working until
now. People take care of their packages because, well, they're their >packages. If packages aren't assigned to maintainers anymore, I fear a >situation of "it's everybody's responsibility, therefore it's nobody's >responsibility".
There are in fact many team-maintained packages, and that's working
well, but it works because people *voluntarily* agreed to collective >maintainership, and those teams are usually rather small anyway, with
an even smaller number of people taking the lead. Those will still
have veto power.
An interesting side effect of your proposal is that Debian's security
will be higer as uploading permissions will not be broad by default.
And I think that a lightweight processe can be designed to allow DDs to >expand their permissions.
Have a nice day,
(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.
(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!)
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?
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: [...]
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.
Is there some way right now for me to say "any Debian contributor with
upload rights should feel free to merge changes and upload this package without needing to consult me at all, and I will subscribe to the packages feed for the package and say something if something happens that I don't like" with a packaging repository on Salsa? And if not, would that be a
good way to start?
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! :)
On Wed, Oct 12, 2022 at 04:09:54PM -0700, Russ Allbery wrote:
Is there some way right now for me to say "any Debian contributor with
upload rights should feel free to merge changes and upload this package
without needing to consult me at all, and I will subscribe to the
packages feed for the package and say something if something happens
that I don't like" with a packaging repository on Salsa? And if not,
would that be a good way to start?
In my understanding this is exactly the purpose of the Debian group on salsa. As [1] says:
Direct commits to repositories in the Debian group by any Debian
developer are implicitly welcome. No pre-commit coordination
(e.g. merge-request or mail) is expected.
[1] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
Tobias Frost <tobi@debian.org> writes:
On Wed, Oct 12, 2022 at 04:09:54PM -0700, Russ Allbery wrote:
Is there some way right now for me to say "any Debian contributor with
upload rights should feel free to merge changes and upload this package
without needing to consult me at all, and I will subscribe to the
packages feed for the package and say something if something happens
that I don't like" with a packaging repository on Salsa? And if not,
would that be a good way to start?
In my understanding this is exactly the purpose of the Debian group on salsa.
As [1] says:
Direct commits to repositories in the Debian group by any Debian
developer are implicitly welcome. No pre-commit coordination
(e.g. merge-request or mail) is expected.
[1] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
What I'm missing, and maybe this is just me not understanding, is the
uploads part. Does that also imply that anyone can just upload? (And
what about the minor protocol parts of that, such as what to put into Maintainer and Uploaders?)
But I was wondering if this was what the Salsa Debian group was supposed
to be and we just haven't really used it very much (possibly because there aren't that many volunteers to upload random packages?).
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
What fraction of security issues we've had in Debian do you think
narrower upload permissions would have prevented?
Le Wed, Oct 12, 2022 at 12:14:35AM +0000, Scott Kitterman a crit :
What fraction of security issues we've had in Debian do you think
narrower upload permissions would have prevented?
Exactly zero. But my comment is not about the past, it is about the
future.
I think that a proper risk assessment would be worth doing, an I also
think that this mailing list is not a proper place for doing it, not
because of secrecy but because of noise and lack of focus. Discussing
the conclusions here would of course be important.
On my side, I would be fine if my upload key would be restricted to the packages that me and my packaging team maintain. I am very unlikely to
need archive-wide privileges in the near future.
Le Wed, Oct 12, 2022 at 12:14:35AM +0000, Scott Kitterman a crit :
What fraction of security issues we've had in Debian do you think
narrower upload permissions would have prevented?
Exactly zero. But my comment is not about the past, it is about the
future.
I think that a proper risk assessment would be worth doing, an I also
think that this mailing list is not a proper place for doing it, not
because of secrecy but because of noise and lack of focus. Discussing
the conclusions here would of course be important.
On my side, I would be fine if my upload key would be restricted to the packages that me and my packaging team maintain. I am very unlikely to
need archive-wide privileges in the near future.
Have a nice Sunday,
IMHO the "risk assessment" for most DDs is already done via NM process. Usually people are mindful of when they upload, and do ask others
for opinions when they do NMU's.
I can understand. However that is not true for a lot of DDs (including me). Many people do need archive-wide previledges. Tobias gave a rather crisp reason
in their mail.
Pierre-Elliott Bécue <peb@debian.org> writes:
Is there some way right now for me to say "any Debian contributor
with
upload rights should feel free to merge changes and upload this
package
without needing to consult me at all, and I will subscribe to the
packages
feed for the package and say something if something happens that I
don't
like" with a packaging repository on Salsa? And if not, would that
be a
good way to start?
If it is
easy for those who need to get archive-wide priviledges, it is also easy
to start without that priviledge as a default.
I really would hate having 2 sets of uploading DDs. One with the
archive-wide privilege, and the one without. Then you'd need to ask for
that right, and potentially have to explain why you need it. This is a terrible idea, with not enough justification (IMO).
On 10/18/22 00:07, Charles Plessy wrote:
If it is
easy for those who need to get archive-wide priviledges, it is also easy
to start without that priviledge as a default.
I really would hate having 2 sets of uploading DDs. One with the archive-wide privilege, and the one without. Then you'd need to ask for
that right, and potentially have to explain why you need it. This is a terrible idea, with not enough justification (IMO).
I think there's some merit for being able to
restrict and expand your own permissions
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.This is my understanding as well, and I agree that Didier's proposal
This is probably my security brain from my day job, but I would prefer to
be able to drop permissions that I'm not currently using, as long as I can get them back easily. It reduces the blast radius of mistakes and compromises.
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 (...)
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.
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*.
What most respondents have gotten across as the bulk of my proposal seems tobe: "we could limit upload rights to certain packages"
... where what I was trying to get across was: "we could team-maintain thecore of Debian (and by extension, other subsets)"
The problem I'm trying to describe (and therefore the mitigations/solutions Iput up for discussion) is that source package realms are not the right granularity for Debian development anymore.
(Sorry for the delay in getting back to that thread. #life)
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 428 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 105:43:56 |
| Calls: | 9,053 |
| Calls today: | 10 |
| Files: | 13,395 |
| Messages: | 6,015,566 |