Hi Lucas,
Am Wed, Aug 20, 2025 at 11:55:00AM +0200 schrieb Lucas Nussbaum:
> My problem here is a "such a policy" and "collaborative maintenance" are
> not well defined. And opposing it to "strict control" is not helpful.
Thank you for the clarification. I perfectly agree. Clear definitions
are important here.
> We have a policy for what is acceptable for NMUs (which sounds fine to
> me) and we have LowThresholdNmu that relaxes this even further (which
> sounds fine to me as well). I understand that you want to go further
> than that, but I don't understand how far.
What I would like to differentiate more clearly is the distinction
between an NMU and a team upload. My (possibly wrong, but to be
discussed) interpretation is that for a package in the Debian/ group I
should be able to do
dch --team
and then upload as part of a collaborative maintenance effort. In
practice, before doing so, I would consult contributors.d.o to check
whether the Maintainer and Uploaders listed are active. If the data
shows activity in the last release cycle, I would contact them before
uploading. If not, I would consider the package de facto orphaned and
proceed.
> Also, it sounds like the problem you are trying to solve is not properly
> defined (or at least that I don't understand it), or that you are
> conflating two different issues (git access rights and upload policy)
> for no real reason.
I see your point, and yes, git access rights and upload rights are
formally separate. However, in all the teams I’m active in, the common
understanding is that every DD (or DM with the right permissions) is
entitled to both — repository access and the ability to upload. So while
these are two different things, they are closely aligned in practice I
experience in my Debian peer groups. Our discussion shows that the
Debian/ group is interpreted differently, which is precisely why I think
we need a clear written policy for it, just like other teams have.
> My background is that I think that some level of ownership is useful,
> because it usually translates to (1) people feeling responsible about
> the stuff that they "own"; (2) people who accumulate expertise about
> this stuff, and sometimes relationships (for example with upstream).
> Of course ownership also has disadvantages, but it's all about a subtle
> balance.
I agree that ownership has real advantages, and ideally both (1) and (2)
would apply. My concern is that, in practice, assumption (1) often
breaks down: people stop feeling responsible for a package — for
perfectly valid personal reasons — but we have no systematic way to
detect this. The result is that packages remain “owned” but are
effectively abandoned. This mismatch is the main problem I want to
address: collaborative maintenance should help us avoid the stagnation
caused by invisible, de facto orphaning.
> Three concrete questions:
> 1/
> Assuming there's a package (hosted in the Debian group) with something
> not very important that could be fixed (severity: minor or severity:
> wishlist). There's consensus in Debian that it's something that should
> be fixed. The maintainer is active.
>
> The NMU policy says that I can upload it to DELAYED/15. Since it's in the
> Debian group, I could also push a branch with the changes, and merge it
> after the package has been accepted.
>
> If the maintainer is listed in LowThresholdNmu, I could upload without
> delay, but it would be impolite to do so without coordinating with the
> maintainer.
>
> Under the policy you envision for the Debian group, is it OK to upload
> without delay and push changes to debian/latest without coordinating
> with the maintainer? If not, where would you draw the line?
If the maintainer is active, I would always coordinate first —
especially after this discussion, since it has made clear that
interpretations differ. For me this is simply a matter of common sense
and respect for the maintainer’s work.
In the past, I might have acted differently, either by mistake or under
the (not always justified) assumption that the maintainer would be fine
with a team upload. Personally, when I move packages into the Debian/
group, it is *because* I want to encourage team uploads. In that case, I
would only expect a short signal (e.g. so I know to git fetch) rather
than prior approval.
So the line I would draw is:
* Active maintainer: coordinate first.
* Inactive maintainer: team uploads should be possible without
unnecessary delay.
> 2/
> What will debian/changelog look like? It's not a "Non-maintainer
> upload", but it's also not a "Team upload". Or is it?
I have been using “Team upload”. To me, that reflects the spirit better:
an upload by another DD as part of collaborative maintenance, not as an
outsider fixing a bug. If consensus emerges that it should rather be
“Non-maintainer upload”, I am fine with that too. What matters most to
me is that the package gets fixed, not the exact label we put on the
changelog entry.
> 3/
> What will the Maintainer and Uploaders fields look like?
I would not change these fields.
> I would fully support a proposal to create a team for team maintenance
> of random packages, with its own salsa group, discussion inside the team
> about e.g. moving to newer packaging standards and push of changes
> to all packages. I would be interested in contributing to such an effort.
>
> What I oppose is the retrofitting of a new, not well defined policy on
> the Debian group, to turn it into a "Debian Collaborative Maintenance
> Team".
Thanks — I think I understand your position better now. Personally, I am
not convinced that creating yet another dedicated team is the right way
forward: the Debian/ group already contains more than 4500 packages
(nearly 1000 with the QA team as maintainer), and moving a large
fraction of them elsewhere would not be practical. To me, it makes more
sense to clarify what being in Debian/ means, and to define better
solutions for when Team uploads are acceptable if at all (for example,
by marking packages as I suggested previously[1] or some other pragmatic
solution). Still, I think we should keep the discussion open to
alternatives, and maybe better options will emerge as we go along.
As I mentioned in my other mail, I will step back a bit from this
discussion and remove lea...@debian.org from CC. I am about to go on
vacation, and while I am happy to have helped spark this necessary
conversation, I’d like this discussion to continue on its own merits,
without being biased by my role as DPL.¹
Kind regards
Andreas.
¹ I’m aware of two schools of thought on “DPL hat etiquette” from
DebConf discussions: some think it’s helpful to clarify whether one
speaks as DPL or not, while others say you can’t just take the hat off.
I’ll leave it to the reader to decide which view applies here.
[1] https://lists.debian.org/debian-devel/2024/12/msg00101.html
--
https://fam-tille.de
