(Note: I am not a Debian Developer, or otherwise officially or
informally affiliated with the Debian Project. I am not eligible to
vote in the forthcoming DPL election. I am merely a member of the
peanut gallery and follower of Debian Linux in general; hopefully a
more beneficial than detrimental member / follower.)
(As an aside, since I wrote this using the GMail web client and
accepted some (but not all) of its editing suggestions, I must
acknowledge that this message was written with AI assistance /
contains "AI slop". (Note, I did revert its suggested change of
"AI-generated content" back to "AI slop," FWIW.) I, however, remain a
human being ("I am a free man!"), tho I know of no way to prove that
as nobody knows you're a dog on the Internet.)
On Sat, Mar 21, 2026 at 7:16 PM Simon Josefsson <[email protected]> wrote:
> Do you have any thoughts on the single-maintainer model vs team-based
> package maintenance?
>
> Do you think anything should change here? If yes, any thoughts on what?
Hi. I am writing this after reading (and rereading) all the messages
on this thread to date, both as received by my email account and also
on the mailing list web archive for debian-vote for this thread
(starting at https://lists.debian.org/debian-vote/2026/03/msg00100.html).
I would like to bring up for discussion the concept of
"LowThresholdNmu" (and the related concept of "LowThresholdAdoption")
as found at https://wiki.debian.org/LowThresholdNmu and
https://wiki.debian.org/LowThresholdAdoption respectively. The LTNMU
page dates back to 2005 and has almost 700 changes, with the most
recent occurring at the end of 2025. The LTA page dates to 2016 and
has had 50 changes, with the most recent occurring in mid-2025.
I note that several Debian Developers (and I assume also Debian
Maintainers, though I don't know that for certain) and teams (not
teams so far for the LTA list) have opted into both of these concepts
/ pages / lists. From a quick review of both pages, I see a number of
Big Name Debian Developers on both lists. (I define BNDD as people I
recognize as participating in the maintenance of important / popular /
core packages in the archive, and/or people I recognize as currently
(or previously) participating in important teams or activities for
Debian, and/or prominent participants in major Debian mailing lists,
and/or members of the Debian Project for a Long Time (where that value
is admittedly subjectively defined).) I also see a number of
well-known and important teams on the LTNMU list.
-----
I would be interested in Ms. Chandran's (and others') thoughts on
these concepts, how they relate (or don't relate) to the question of
single-maintainer vs team-based package maintenance, and related
questions or concepts.
Are the ideas of LTNMU and LTA sufficiently well known and popularized
amongst the community maintaining packages for Debian Linux (including
official Debian Developers (DDs) and Debian Maintainers (DMs), as well
as non-officially-affiliated developers)? If they are well known
enough, are they generally working as intended and having the desired
effect? If they are not well known enough, how can they be better
advertised and marketed? If they are well known enough and are having
the desired effect when used, but are generally unpopular among
developers in general (even when doing so would be of value to the
developers), why is that and can they be improved to cause developers
to be more inclined to use them?
For developers currently on either (or both) of these lists, how do
they perceive their presence on these lists has affected their work
and/or the affected packages? (Has there been any effect at all!?)
If there has been an effect, has it generally or usually been
perceived as desirable (or undesirable!)? Are they glad they added
themselves to these lists, regret having done so, or have no opinion?
For developers maintaining packages which they would be willing (or
even actively desire!) to have team-maintained, but who cannot find an
existing team suitable for their package (or a team willing to adopt
their package, perhaps with the developer joining the team as a
member), and do not desire to start a team for the package (and/or
related packages) for whatever reason, might LTNMUs serve as a useful
step towards the package becoming team-maintained? Have there been
practical examples of this happening?
Same question for packages that developers would be willing to
co-maintain with others. (I note that ISTM that co-maintaining a
package seems distinctly different from team-maintaining a package, so
this should be a separate question from the above.)
For developers who strongly believe that team-maintenance of packages
is the ideal to strive for whenever possible (as someone famous once
said, "This is the way"), how do they consider the LTNMU and/or LTA
lists? Do they find a package's presence on these lists sufficient
justification that the package does not necessarily "need" team
maintenance (even if they still feel it "should" be team-maintained or
that they would prefer team maintenance)? If they do not find that to
be true, what can be done to persuade them otherwise? (This presumes
the existing sole maintainer finds team maintenance of the package
unacceptable even though they find its presence on the LTNMU and/or
LTA lists acceptable.)
-----
I acknowledge and accept previous messages in this thread mentioning
developers who, for various valid reasons, do not want to or cannot
participate in the team maintenance of some or all of the packages
they currently solo-maintain. For instance:
1) people who find extensive communication and/or interaction with
others in the maintenance of packages (beyond what already occurs
during solo package maintainance) is an excessive or unacceptable
burden;
2) people who find having to participate in a team to maintain
packages they create and/or care about reduces or eliminates the value
they receive from participating in Debian development, leading them to
reduce or altogether stop their contributions to Debian;
3) people who find a given package so difficult or complex to maintain
that team maintenance would actually be detrimental to the package;
4) people who find a package they solo-maintain so fundamentally or
critically affects other packages they solo-maintain (and which latter
packages they are unwilling or unable to team-maintain) that
team-maintaining the first package would be detrimental to the second
solo-maintained package, even if the developer would otherwise agree
to team-maintain the first package;
5) and I'm sure there's plenty of other reasons as well.
Would any such developers find it acceptable or even desirable to be
on the LTNMU and/or LTA lists for some or all of their packages if
they are unwilling or unable to participate in team maintenance of
those packages, but are willing and able to maintain packages that are
LTNMU'd or LTA'd? If so, how can this be promoted and encouraged?
I also acknowledge that some developers (let's call one "Abe") may
feel that another developer's ("Bea's") placement on the LTNMU and/or
LTA lists for some or all of Bea's packages is insufficient to
overcome Abe's perception that Bea "owns" those packages. This
perception might make Abe feel that Bea would not welcome their
potential contributions to this package (despite Bea and the package
being on this list), preventing Abe from even attempting to
contribute. Conversely, if the same packages were team-maintained
(even just by a single-member and/or single-package team), Abe would
perceive their potential contributions as welcomed and even desired.
What can be done to reduce or eliminate such a perception by Abe
concerning a package on the LTNMU or LTA lists in the general case?
Further, what might be possible to do if we add the constraint that
Bea would be willing to maintain these packages within a team (e.g.
does not object to the idea of a team for these packages if one
existed and would be willing to work as a member of such team) but
does not themself desire to found a team and/or does not want to
"gratuituously" create "unnecessary" teams (and further possibly /
presumably has looked in the past to find an already existing team
suitable for this package but could not find one they thought made
sense for the package)?
-----
Thank you for taking the time to read (and perhaps even respond!) to
this message. Hopefully you found it useful and interesting.
I am currently subscribed to debian-vote, so if you reply to this
message there I should receive your response via the list; however, I
do not object to also being directly CC'd on the response if that's
your usual method. I have this thread starred in GMail so I'll be
more likely to notice any response.
If you find it worth a reply but do not want to publicly respond
directly to debian-vote (presumably most likely to debian-devel
instead), you have my explicit permission to quote content I have
written there in whole or part, with or without attribution, as you
see fit. However, I am not currently subscribed to debian-devel (but
am happy to follow it via the web archive if necessary). If you
respond there and want me to see it, please CC me directly or let me
know so I can follow the thread on that list's web archive.
Again, thank you for your time.
Joseph
