Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
I demand that Arno Töll may or may not have written... [snip] 2) ... Drive-by sponsoring does not work. It's annoying and back-breaking to the sponsored maintainer to have a package containing lots of fixes and maybe a new upstream version but nobody who uploads the you've been working on (yes, that happens) mercurial-buildpackage. I recall being told that it should be rewritten in another language. I don't disagree *but* that would involve more change and, possibly, make the changes a lot less reviewable (and might introduce Many Bugs™). My choice here is to get what I've done to it in the archive before any re-implementation is done. (Incidentally, I'm using it for maintenance of the various xine packages.) 3) It's not helpful because the sponsor, at best, has a rough and cursory understanding how the package works. There's possibly a case for enabling DMUA without requiring a sponsored upload. But it would have to be case-by-case, and it's definitely not something to be done lightly. 4) It's not clear at all how a bug fix could be uploaded to Debian at all, so the package might be in bad shape soon as nobody who /could/ upload feels responsible for it and those who care /can't/ upload. Packages get left to rot. DMs don't bother with them because they've been (effectively) ignored before; some may create external repositories for the packages instead... [snip] -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Press SPACE or click mouse to continue -- 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/52a6383cc4%lists...@moreofthesa.me.uk
Maintainers, teams, Uploaders, DMs, DDs, etc.
It's evident from recent conversations in various places that we are confused about: - what Maintainer and Uploaders mean - who is entitled to do what when - in some cases, the distinction between ability and permission etc. I'm going to try to set out my understanding of the current best practices, with some open questions and suggestions for improvement. I'm proposing this as an alternative to the existing plan to change the way DM permission works. But firstly I want to explain an important principle: the distinction between ability and permission. In any complex collective endeavour, there will be both access controls that actually prevent some people from taking certain acts, and ideas (whether stated formally and clearly, or informally and vaguely) about what should be done when and by whom. Access restrictions are annoying to implement and work with so they should be minimised where possible - but they are a necessary backstop to prevent abuse. In general access restrictions need to be flexible enough that it is possible to revoke the permissions of someone who is using their technical ability in ways that are considered undesirable by whoever is supposed to be in charge. But, provided that there are sufficient facilities for reverting misdeeds and mistakes, they do not need to be more complex than that. So for example, DDs have enormous theoretical power but there are strong and well documented social controls on how they should exercise that. I think as a matter of principle that the same principle should apply to DMs: it is easy to remove a misbehaving DM from Uploaders. So it is not necessary to have technical measures that prevent a DM mentioned in Uploaders from violating the package's uploading rules, bypassing review processes, or whatever. Instead, when a package team or lead maintainer accepts someone into Uploaders we should clearly communicate to the new uploader what is expected of them, and then we should trust them to do as we have asked. So firstly, let me go through the actual places where we as a project store information about the maintenance structure of a package: * Maintainer field * Uploaders field * DM-Upload-Allowed field * The DD keyring * The DM keyring * Team membership lists kept elsewhere (eg, a team webpage or wiki page, mailing list membership, or whatever) * Team practices/processes/policy agreements, documents, etc. (which might include anything from informal private emails to formal process and governance documents) The questions that need to be answered for a package are: * Who is (supposedly) doing most of the work. * Who makes final decisions about the package; this includes arbitraring disputes, delegating authority, revoking such delegation, etc. The identity of the people with this responsibility needs to be accessible to the project as a whole so that people who are unfamiliar with the package can see whose opinions are definitive. This information does not normally need to be used automatically by the project's support infrastructure. I'm going to call these people the maintainers of the package. They might be DDs, DMs, or contributors without a key in the keyring. Currently this information is sometimes in the Maintainer field; sometimes in both the Uploaders and Maintainers fields; and sometimes somewhere else completely (eg a team wiki page). Normally the maintainers would be the people who are doing most of the work. Sometimes we have provisional maintainers who are neither DD or DM; in those cases the maintainer works under the supervision of their sponsors. c. Who is entitled to prepare a non-NMU upload of the package. This information needs to be accessible to the project as a whole. Particularly a potential drive-by sponsor needs to know whether the upload they are sponsoring is by someone entitled to prepare such an upload. And the archive software needs to know whether to permit an upload. Currently this information is sometimes in the Maintainer field; sometimes in both the Uploaders and Maintainers fields; and sometimes somewhere else completely (eg a team wiki page). d. Who is morally entitled to perform various other actions with respect to the package, such as manipulating bugs, committing to its vcs, etc. This information does not need to be available to people outside the team involved with the package. If disputes arise they can be dealt with by the maintainers, and if necessary the maintainers can invoke various enforcement mechanisms to stop misbheaviour. e. What process should someone preparing a non-NMU upload follow? Eg, is there a VCS that everything should be committed to ? Are non-emergency uploads supposed to be reviewed somewhere ? Are some of the people who are entitled to upload supposed only to do so after explicit indication by someone more senior that they should
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
* Ian Jackson ijack...@chiark.greenend.org.uk [120613 17:35]: 5. Introduce a new conventional location for information useful to NMUers, debian/README.nmu Explicitly state that someone preparing or sponsoring an NMU should consult this file. Statements in this file may supplement, but do not overrule, the NMU criteria established by the Developers' Reference, by the release team, or elsewhere. Explicitly state that NMUers are NOT necessarily required to consult README.maintain. Adding something for NMUs in the package without adding some way to give more information for NMUs outside the package might result in information getting in there that will usually be outdated when an NMU is needed. (after all, NMUs are especially common when noone else did an upload for a longer time, so a upload just to get that file within the package is also unlikely to have happened). Bernhard R. Link -- 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/20120613163535.ga30...@client.brlink.eu
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Hi, first: thank you. Recent threads show, we clearly need a discussion like this and hopefully people will take it as an opportunity to leave this thread a bit more enlightened. On 13.06.2012 17:35, Ian Jackson wrote: Instead, when a package team or lead maintainer accepts someone into Uploaders we should clearly communicate to the new uploader what is expected of them, and then we should trust them to do as we have asked. A DM can't upload anything, just because of his being as a DM. It's the uploader field AND the DMUA flag which matters. So, if you don't trust a person to upload packages, don't set the flag. Since that's per package and not per person and package, this might have some side effects, but Ansgar is about to change that, so we do not need to worry too much about that (again). c. Who is entitled to prepare a non-NMU upload of the package. Particularly a potential drive-by sponsor needs to know whether the upload they are sponsoring is by someone entitled to prepare such an upload. And the archive software needs to know whether to permit an upload. By the way, for a sponsored maintainer there is no trusted evidence at all whether you are sponsoring an upload of said person or of an impostor. Drive-by sponsoring makes this even more complicated and is not helping anybody. We should stop advocating drive-by sponsoring at all. 1) You upload a package without feeling responsible for it over a longer term. Thus, that package is virtually stuck forever as is in Debian because ... 2) ... Drive-by sponsoring does not work. It's annoying and back-breaking to the sponsored maintainer to have a package containing lots of fixes and maybe a new upstream version but nobody which uploads the you've been working on (yes, that happens) 3) It's not helpful because the sponsor, at best, has a rough and cursory understanding how the package works. 4) It's not clear at all how a bug fix could be uploaded to Debian at all, so the package might be in bad shape soon as nobody who /could/ upload feels responsible for it and those who care /can't/ upload. f. Are there specific things that an NMUer should watch out for ? Currently we have no general way of finding these. The closes is the LowThresholdNmu wiki page. There clearly are. Just read http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu And hopefully some other people regularly sponsoring or doing themselves unacceptable NMUs do so as well. * Individual DD or DM maintainer, perhaps with co-maintainers. The single individual principal maintainer is listed in Maintainer and makes all decisions. Co-maintainers are listed in Uploaders and may make their own uploads and may in general make decisions where not contradicted by the principal maintainer. There may or may not be any information for NMUers. I do not like that idea of introducing more and less important people and classes for a package. That's against our spirit. However, as I said in IRC: De-facto that's the case for a long time already, so be it for the sake of just stopping to trick ourselves here. I think that part of your suggestion is improvable, though. After all I do not think there is (should be) any difference in authority at all - whether someone is listed as a maintainer or as a uploader does not matter to me. The rationale for the Uploader field is a technical one and has nothing to do with actual powers. It clearly should have been named different, however. 1. Change the definition of the Maintainer field to permit multiple entries. There were probably technical reasons back then when introducing Uploaders. Maybe someone knows. 2. Explicitly state that being listed in Uploaders does not in itself imply general authority over the package; general authority is reserved to maintainers. That would be a sad day for Debian as a whole because it introduces a class society within Debian. But again, de-facto that's a truth already. 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. That's a good idea I like. 5. Introduce a new conventional location for information useful to NMUers, debian/README.nmu Likewise. Maybe we could stick both, the maintainer and the NMU information README.source though, as people suggested in IRC. It doesn't seem to me that there is any need to change the archive machinery to handle DM permissions differently. There are lots of reason if you look into the dak source and check how exactly DM upload permissions are hacked into it. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Ian Jackson ijack...@chiark.greenend.org.uk writes: So for example, DDs have enormous theoretical power but there are strong and well documented social controls on how they should exercise that. I think as a matter of principle that the same principle should apply to DMs: it is easy to remove a misbehaving DM from Uploaders. For some values of easy. It requires a sourceful upload for possibly no other reason than to remove an uploader. That's a waste of time, not only for the maintainers, but the buildds and archive software too. Would the package take long to compile, it would be even worse. We can't compare this to the case of DD's, because DD upload rights are only governed by social customs and the keyring, the DMs have *additional* restrictions, which currently are tied to the source package. So it is not necessary to have technical measures that prevent a DM mentioned in Uploaders from violating the package's uploading rules, bypassing review processes, or whatever. Instead, when a package team or lead maintainer accepts someone into Uploaders we should clearly communicate to the new uploader what is expected of them, and then we should trust them to do as we have asked. Well, one of the reasons DMs are not DDs, is because they do not have the same rights as DDs do: they can't, and in my opinion, shouldn't be able to upload pretty much any package without further restrictions. If they would, they'd technically have the same upload rights as DDs do, with a fraction of the experience, and without going through NM. I don't think that would be wise. (No disprespect meant for DMs, mind you) However, this (whether we need the extra upload restrictions for DMs), I believe is not strictly related to the proposal, which, to my reading, was more about moving the DM-Allowed field out of the source package, and a few other things. The questions that need to be answered for a package are: [..] * Who makes final decisions about the package; this includes arbitraring disputes, delegating authority, revoking such delegation, etc. [...] I'm going to call these people the maintainers of the package. They might be DDs, DMs, or contributors without a key in the keyring. Currently this information is sometimes in the Maintainer field; sometimes in both the Uploaders and Maintainers fields; and sometimes somewhere else completely (eg a team wiki page). Normally the maintainers would be the people who are doing most of the work. Sometimes we have provisional maintainers who are neither DD or DM; in those cases the maintainer works under the supervision of their sponsors. So far, I agree. c. Who is entitled to prepare a non-NMU upload of the package. This information needs to be accessible to the project as a whole. Particularly a potential drive-by sponsor needs to know whether the upload they are sponsoring is by someone entitled to prepare such an upload. And the archive software needs to know whether to permit an upload. Currently this information is sometimes in the Maintainer field; sometimes in both the Uploaders and Maintainers fields; and sometimes somewhere else completely (eg a team wiki page). There's also the case of DM-Allowed: yes. If someone is listed as maintainer, but is not a DD, then my understanding is, that he is not entitled to upload. (Hence, should not be in Uploaders, either, unless DM-Allowed: yes is set) This looks silly, though, and inconsistent, and very easy to miss when sponsoring or working within a larger team. Nevertheless, in case the maintainer is not a DD, he either needs a sponsor, or must be a DM, with the package having DM-Allowed: yes. This also presents a problem when adopting packages, because if the adopter is a DM, someone must sponsor his first upload or set DM-Allowed: yes otherwise in a separate upload - neither of which is particularly friendly towards the DM (nor anyone else, really). Would this restriction get untied from the source, the former maintainer could grant upload rights without having to do a sourceful upload, and everyone wins, and no rights get harmed either. e. What process should someone preparing a non-NMU upload follow? Eg, is there a VCS that everything should be committed to ? Are non-emergency uploads supposed to be reviewed somewhere ? Are some of the people who are entitled to upload supposed only to do so after explicit indication by someone more senior that they should do so ? Again this information doesn't generally need to be available to people outside the packaging team. However, if there are significant and important processes that should be followed, a drive-by sponsor should be able to find them easily so that they can double-check that the person preparing the upload (the sponsee) seems to be doing the right thing. Currently this information is, if available at all, to
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Hi, as a clarification, because I was pointed to it: On 13.06.2012 18:54, Arno Töll wrote: Drive-by sponsoring makes this even more complicated and is not helping anybody. We should stop advocating drive-by sponsoring at all. ... with the exception of evident cases like RC bug fixes, emergency uploads or any other kind of upload where an urgent fix is needed. That's clearly not what I meant to address. I am merely addressing the phenomenon of mass drive-by sponsoring of random packages. Yes, that happens quite regularly and I do not think this is how sponsoring should work at all. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
On Wed, Jun 13, 2012 at 1:35 PM, Arno Töll wrote: Hi, as a clarification, because I was pointed to it: On 13.06.2012 18:54, Arno Töll wrote: Drive-by sponsoring makes this even more complicated and is not helping anybody. We should stop advocating drive-by sponsoring at all. ... with the exception of evident cases like RC bug fixes, emergency uploads or any other kind of upload where an urgent fix is needed. That's clearly not what I meant to address. I am merely addressing the phenomenon of mass drive-by sponsoring of random packages. Yes, that happens quite regularly and I do not think this is how sponsoring should work at all. Is that worse than the package being completely ignored? I'm really not sure what your definition of drive-by is. Sometimes I'll make time to look at a package interesting me, I'll communicate with the sponsoree, upload it if they address my concerns, then follow it for a little while to make sure nothing bad happened. Is that a drive-by? Best wishes, Mike -- 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/CANTw=mpor0iogzapdsltdjhhq8v6bywgnsg4p4pzeqkhfdd...@mail.gmail.com
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Hi, On 13.06.2012 19:46, Michael Gilbert wrote: I'm really not sure what your definition of drive-by is. Sometimes I'll make time to look at a package interesting me, I'll communicate with the sponsoree, upload it if they address my concerns, then follow it for a little while to make sure nothing bad happened. Is that a drive-by? It's a drive-by upload if you disappear thereafter and you are not replying to you sponsored maintainer's mails asking you for a follow-up upload. You are just describing how many (most?) sponsorship relations start and that's perfectly fine. It's what happens (or rather: what's not happening) afterwards which worries me in some cases. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
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
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Le Wed, Jun 13, 2012 at 06:47:32PM +0200, Gergely Nagy a écrit : I think that would fit into debian/README.source nicely. Le Wed, Jun 13, 2012 at 06:54:35PM +0200, Arno Töll a écrit : README.source though, as people suggested in IRC. Le Wed, Jun 13, 2012 at 11:25:43PM +0200, Ansgar Burchardt a écrit : I think this information could be located in README.source just as well. Hi all, I also think that README.source could include information about how the package is maintained and how to prepare uncoordinated uploads when they are necessary. There is a proposition to explicitely recommend in the Debian Policy to document in README.source how to use or behave with the VCS where the source package is managed, and this could be extended to other informations as well. http://bugs.debian.org/495233 Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120613235114.gb32...@falafel.plessy.net
Re: Maintainers, teams, Uploaders, DMs, DDs, etc.
Arno Töll a...@debian.org writes: On 13.06.2012 17:35, Ian Jackson wrote: 1. Change the definition of the Maintainer field to permit multiple entries. There were probably technical reasons back then when introducing Uploaders. Maybe someone knows. I don't know of technical concerns there. But I do recall many discussions where a proud benefit of Debian was said to be that every package has a single person primarily responsible for it, because this mitigates the diffusion of responsibility we humans are prone to. I realise the recent trend has been toward nominating a team as “the” maintainer. -- \ “Whenever you read a good book, it's like the author is right | `\ there, in the room talking to you, which is why I don't like to | _o__) read good books.” —Jack Handey | Ben Finney pgpZmmRHSQHaX.pgp Description: PGP signature
