On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote: > Maybe an example will help get us on the same page. Russ seems to > have the impression that my proposal is somehow a license to push > unwanted changes at a maintainer. That is not true. > > Let's consider mlocate as a hypothetical: > > - The contributor wants a new upstream for better hurd support > - He prepares an nmu of that new upstream (making sure to not modify > the maintainer's build setup and packaging style) > - He convinces a DD that this is worthwhile to sponsor, and that DD > decides that he is willing to take the social risk involved if > something goes wrong > - The DD uploads the package to DELAYED/<whatever we agree is long > enough> and sends an nmudiff to the mlocate bts > - The maintainer gets the mail, cancels the upload, and says to the > contributor "for me hurd support is not enough to take the risk of a > new upstream upload" > - In this case, the contributor would probably say ok that's fine, and > not push it further > - But if he really thought it was that important, he would take it to > the Tech Committee, and in this case, the committee would most likely > side with the maintainer's opinion
In this scenario the contributor should have talked to the maintainer before requesting a sponsor. http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu | Have you clearly expressed your intention to NMU, at least in the BTS? It is | also a good idea to try to contact the maintainer by other means (private | email, IRC). If the maintainer is usually active and responsive, have you | tried to contact them? In general it should be considered preferable that | maintainers take care of an issue themselves and that they are given the chance | to review and correct your patch, because they can be expected to be more aware | of potential issues which an NMUer might miss. It is often a better use of | everyone's time if the maintainer is given an opportunity to upload a fix on | their own. Regards, Bart Martens -- 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/20121101225959.ga7...@master.debian.org
