XPost: linux.debian.project   
   From: simon@josefsson.org   
      
   Dominik George  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   
      
   --=-=-Content-Type: application/pgp-signature; name="signature.asc"   
      
   -----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-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)