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
Attachment:
signature.asc
Description: OpenPGP digital signature