Hi, Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > I think the first three can be fixed relatively simply. I propose the > following changes: > > 1. Change the definition of the Maintainer field to permit multiple > entries. > > There are currently four different entities (3 humans and a > corporation) which use a comma in a Maintainer field, in only 13 > different source packages. None of these commas are essential to > comprehension (indeed in principle those same entities might have > to have variants of their identification without commas, suitable > for use in Uploaders). All but one of these Maintainer fields are > already violations of policy 5.6.2 which says that the Maintainer > field must be in "RFC822 format" (a bit vague, but clearly excludes > bare commas). > > So this is an easy change.
This was suggested when the Uploaders field was originally introduced, but not done in order to avoid breaking tools that rely on having only one entry in the Maintainer field[1]. [1] <http://bugs.debian.org/101815> I find it also interesting to note that Uploaders was originally called Maintainers in said bug report. > 2. Explicitly state that being listed in Uploaders does not in itself > imply general authority over the package; general authority is > reserved to maintainers. I disagree with this quite strongly: while it may be current practice that some maintainers have more to say about a particular package than other maintainers, this is currently part of the *private* relation between maintainers. To outsiders they can (and should!) still be peers. Your suggested change would instead formally introduce 2nd class maintainers which I would not like to endorse. I do not think I would have felt as welcome in Debian as I did if this had been the case. > 3. Introduce a new conventional location for information about a > maintenance team and a package's maintenance practices, > debian/README.maintain > in the source package. > [...] > > 5. Introduce a new conventional location for information useful to > NMUers, > debian/README.nmu I think this information could be located in README.source just as well. > It doesn't seem to me that there is any need to change the archive > machinery to handle DM permissions differently. I am still not sure what you find so bad about the proposed changes. But let's go through all changes to try and keep everyone happy: a, Drop the requirement that DMs cannot sponsor packages they can upload themselves. b, Identify DMs by fingerprint instead of name/mail. This is how dak sees everyone else and avoids problems with multiple uids (as dak only knows about one of them). c, Move the DM-U-A flag to projectb instead of the source package. Also use an explicit list for upload permissions instead of having it implied by Maintainer/Uploaders (which we need anyway as we want to use fingerprints). d, Allow *only* DDs to change upload permissions. This is unrelated to the other changes. We could technically allow DMs that have upload privileges for a package to grant that to others as well, but I do not believe this to be intended by the DM concept. None of these changes are intended to take anything away from DMs which I get the impression you believe. a, and b, certainly don't as we drop some restrictions currently implemented in dak. c, is mostly a change how DM is implemented; it also allows a DD to grant upload permissions to multiple packages at once when he is convinced the DM can handle them (eg. a group of similar or closely related packages). I also don't believe d, should be a large problem for DMs in practice. They should already know a DD they can ask to set DM-U-A for them just as they would need for a package where the other maintainer was not already a DM. In fact your proposed changes might be more restrictive to both DMs and non-D[DM] maintainers as it makes it harder for them to find sponsors when they are "only" listed in Uploaders. We already don't have enough people mentoring others and I doubt having them check additional things (May an Uploader change source format for this package? May he switch packaging tools? ...) would bring improvements. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehpigazs....@deep-thought.43-1.org
