Re: unmaintained packages hidden by team maintenance

Simon Josefsson <[email protected]> Fri, 20 Feb 2026 14:50:28 +0100
Newsgroups gmane.linux.debian.devel.project
Message-ID <[email protected]>
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)
-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmmYZqQUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFom11AP4nWu+Jwf81
ZGU4Y/+Be+QgtOYq3QtZsuCZs8+H0JDvJQEAwfcg6yBUBpnlMHmqRbxnGyS912E9
kwILTRYqm/tsMw0=
=qeA+
-----END PGP SIGNATURE-----