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-----