On Tue, Mar 24, 2026 at 11:07:31PM +0100, Simon Josefsson wrote: >... > Marc Haber <[email protected]> writes: > > > Adduser, on the other side, I would love to have team maintained. Are > > you planning to fine me because I have failed to assemble a team > > around adduser? Or what do you have in your mind to make people do > > team work if a team fails to form? > > > > Will I get people assigned to help with adduser? Who is going to > > manage those non-volunteers? > > > > Team maintainance is a good thing. But forcing or requiring it is not > > going to work. Don't assume that there are people queuing up to > > co-maintain packages. > > I share your reaction, but also: please don't assume poeple will NOT > randomly appear if there is a team around packages. You don't > necessarily need to do anything beyond changing the 'Maintainer:' field. > > I believe the rust/python/go/ruby/etc teams in Debian all prove, to some > extent, that merely having a team around packages somehow leads to a > dynamic that make people appear and contribute. >...
An important factor is how much mentoring/learning is required for making non-trivial contributions *e.g. updating to a new upstream version) to a package. For the majority of packages the Debian packaging is technically trivial. > I wish there was a 'Debian Developer Team' where all packages could be > welcome to. >... I do consider it odd when people argue with "orphaned" in package removals, since the Debian QA Group is basically such a team. Packages like LibreOffice or Firefox are formally maintained by teams, but each had de facto just a single maintainer during the past 20 years since there's a lot of upstream and packaging one has to understand before making non-trivial contributions to such a package. For such complex packages it is unlikely that people will just randomly appear to join the team. adduser is not a huge package, but this is a package where it is beneficial that we have one maintainer already for over 20 years since the maintainer also has to be upstream and this is the kind of package where it's easy to break a lot with a simple mistake. Maintaining trivial and non-trivial packages should really be different discussions. > /Simon cu Adrian
