Bug#798476: unmaintained packages hidden by team maintenance

Simon Josefsson <[email protected]> Fri, 20 Feb 2026 14:50:28 +0100

Newsgroups	gmane.linux.debian.devel.policy
Message-ID	<87o6ljjzh7.fsf__6579.74841758318$1771595619$gmane$org@josefsson.org>

Dominik George <[email protected]> writes:

> Hi,
>
>>this is the whole point of making the Uploader field optional.  When absent, it
>>means that every team member is equally in chage for the packag
>
> Ah no, please not! At least not with what I understand as "in charge of".
>
> Let's say someone joins the Python packaging team, and uploads a
> package without an Uplaoders entry. Now I am in charge of this
> package.

No.  It means the team is in charge.

> What does this entail? Do I constantly have to monitor upstream? Do I,
> personally, get all the maintainer duties? And everyone else in the
> team as well?

No.  The package is a shared responsibility, which is my perception of
the point of doing team-maintained package in the first place.  If you
don't want shared responsibility, then why team-maintain something?

> That won't work. I don't want all maintainer duties for all the
> thousands of packages under the Python team, and if "everyone" is in
> charge, then noone is in charge. Instead, if noone cares enough to put
> on the "in charge" hat, the package should be dropped from the team.

Huh?  What's the point of having team-maintained packages at all with
that perspective?  Maybe it helps to think about this differently, and
consider that it is possible to not have a single-maintainer strong
ownership model of package maintainance.

It is fine for people to have the single-maintainer model and still be
able to do what they want.  Nobody has suggested to remove the Uploaders
field.  Only to make it optional, for those who prefer another way.

> I may have missed essential parts of the discussion, but as I see it,
> making the Uoploaders field optional, with the semantics described
> above, would *ensure* that all team maintained packages fly under the
> radar, contrary to what it should do.

I don't think anyone has suggested your semantics, or that it follows
from anything part of the Debian Policy or any other document.

/Simon

signature.asc (application/pgp-signature, 1.2 KB)