On Thu, Nov 01, 2012 at 07:10:06PM -0400, Michael Gilbert wrote: > On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote: > > 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. > > This would be something that his potential DD sponsors would have > taken into consideration before agree to a sponsorship.
Well OK, then the contributor should have talked to the maintainer before requesting a sponsor, and the sponsor should have verified that before uploading. > So, yes, I've > taken a bit of liberty in terms of assuming that a DD could be > convinced that mlocate was in a state where this needs to happen when > clearly its not. > > Since this is a hypothetical, I'm free to set constraints, so please > assume mlocate were in a worse state than it really is above. I commented on the the described scenario, not on mlocate. But also for mlocate, I don't see any bug "NMU intent" in the bts, and Svante Signell has confirmed that bug 669368 was not an NMU intent. http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mlocate I'm not sure how all this would fit in the debate on Lucas' proposal about orphaning. I guess that mlocate is not the perfect example to evaluate Lucas' proposal with. 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/20121102082426.ga...@master.debian.org
