Re: Sponsoring questions; are sponsored NMU's allowed?
Wouter Verhelst <wouter@grep.be> writes:
> On Sat, Jun 05, 2004 at 10:19:48PM +0200, Goswin von Brederlow wrote:
>> Steve Langasek <vorlon@debian.org> writes:
>>
>> > On Sat, Jun 05, 2004 at 06:41:02PM +0200, Jeroen van Wolffelaar wrote:
>> >> A last question: what about sponsored NMU's? I've had at least one NMU
>> >> ready to be sponsored & uploaded, plus pondered to do it multiple times,
>> >> often invited by DD's. Is it allowed as a non-DD to do NMU's? Or are
>> >> NMU's really a DD-only privilege?
>> >
>> > The comments about sponsored NMUs were actually mine. I don't believe
>> > there's any valid reason for sponsored NMUs; the responsibility of the
>> > NMU preparer is such that there should be exactly 0 difference between
>> > the actions taken by a DD uploading his own NMU and a DD uploading an
>> > NMU at the prompting of a non-DD, so there's no sense in referring to
>> > this as a sponsored NMU unless the DD is doing something wrong. (E.g.,
>> > all patches that are part of an NMU should be in the BTS before the NMU
>> > is done, so the DD can easily grab them from there without having a
>> > non-DD prepare a source package that includes them.)
>>
>> The difference is that the Changed by field will read the name of the
>> sponsoree instead of the DD sponsoring.
>
> If that is all the difference there is, then that difference is
> meaningless.
>
>> Questions, blame, followup should idealy be handled by the sponsoree
>> while the DD only has to make sure that that happens.
>
> No.
>
> Being a Debian Developer means a hell of a lot more than just "having a
> debian.org account", or even "being able to upload packages to the
> Debian archive". Thousands of users effectively trust Debian Developers
> -people they don't know- with root on their machine. As a Debian
> Developer, it is your duty to ensure that this trust is justified, and
> remains so. You _cannot_ do that by just uploading anything sent to you
> by any random person[1]; it requires careful review of any changes you
I was talking post upload. The DD has to audit the patches no matter
what. Nothing changes there.
> make, ensuring the changes do what you want them to do. Anything else
> will jeopardize the integrity and the security of our system; for all
> you know, that helpful user with the harmless-looking patch (at least on
> first sight) might actually be an evil cracker planning to do a DDoS,
> with a remote root in disguise. That hasn't happened yet, but there's no
> reason to assume it won't ever happen.
>
> Therefore, doing a sponsored upload is (or at least, should be) quite
> some work, sometimes more than a "normal" one.
>
> On the subject of NMU's, these should generally be small updates to fix
> major problems. It should not be a major overhaul of the package, or a
> huge patch possibly breaking more things than it fixes; in most (though
> not all) real-life situations, an NMU is there for stuff such as "Here's
> a patch to fix foo" - "Thanks, looks good, but I don't have the time to
> upload; would you mind?" Even if the maintainer is MIA or not
> responsive, an NMU shouldn't be very intrusive; if it is, the right
> thing to do would not be to do an NMU, but to take over maintenance.
>
> Therefore, preparing an NMU should generally _not_ take much time (if it
> would, you shouldn't be doing an NMU).
>
> Given both of the above conclusions, it's not hard to understand how the
> work done for sponsoring an NMU will often take more time than preparing
> the NMU itself, if both are done right. Therefore, a sponsored NMU is
> generally either a waste of time, or an abuse of procedures. Instead of
> trying to get a sponsored NMU done, a non-DD should generally try to
> provide patches (to either the maintainer or the BTS).
And if they have been sitting in the BTS for weeks? Month? Years?
> [1] Yes, I know there are people who actually do just that. These people
> don't deserve our users' trust, and thus, should be thrown out, IMNSHO.
>
>> And if it turns out that the last X uploads have all been done by the
>> same non DD they can more easily adopt a package than if every upload
>> has a different DD on it.
>>
>> Give credit where credit is due. If someone wrote patches, looked the
>> package over, fixed bugs and invested all his time why not put his
>> name on it?
>
> There are several ways to credit people.
>
> foo (1.0-1) unstable; urgency=low
>
> * Fix to ensure libfoo does not bar the system anymore when fork()ed.
> Thanks, J. Random Hacker; Closes: #999990
> * Make sure we clean up (i.e., close all open files, not just the one
> we referenced last) after SIGHUP. Thanks, J. Random Hacker; Closes:
> #999991.
> * Tracked down all calls to sprintf(), and replaced them with
> snprintf(), to avoid buffer overflows. Whew, good job! Thanks, J.
> Random Hacker; Closes: #999992.
>
> -- Wouter Verhelst <wouter@debian.org> Sat, 05 Jun 2004 23:05:53 +0200
>
> Who did the most work here? Me, or J. Random Hacker?
>
>> Security wise it also makes sense to keep seperate records
>> of who wrote the code and who OKed it for debian.
>
> Absolutely.
And for me that means that the Changed-By field reflects who changed
the source.
If the DD collects a set of patches from the BTS and NMUs them then he
added the patches to the source. He changed it, as you would have in
the above, even if you collected 3 patches by the same person. The DD
would be making an NMU and he would be writing the Changelog
entry. Apart from maintainers doing it this should be the more common
case.
On the other hand if I spend hours collecting, writing, merging and
testing patches and send a complete patch for an NMU including
changelog to the BTS and ask a DD to sponsor just that one complete
patch, possibly by giving him the source directly, then I have changed
the source. My name should be in Changed-by while the DD gets his own
name into the Maintainer field of the changes file. Thats what I would
call a sponsored NMU.
How would you write that into the changelog if you don't sponsor an NMU?
foo (1.0-1) unstable; urgency=low
* Fix to ensure libfoo does not bar the system anymore when fork()ed.
Thanks, J. Random Hacker; Closes: #999990
* Make sure we clean up (i.e., close all open files, not just the one
we referenced last) after SIGHUP. Thanks, J. Random Hacker; Closes:
#999991.
* Tracked down all calls to sprintf(), and replaced them with
snprintf(), to avoid buffer overflows. Whew, good job! Thanks, J.
Random Hacker; Closes: #999992.
* The above patches have been merged, corrected and tested by
J. Helpfull Non-DD
-- Wouter Verhelst <wouter@debian.org> Sat, 05 Jun 2004 23:05:53 +0200
Like that?
That way you would give credit to the person doing the work. But why
not just leave J. Helpfull Non-DD in the Changelog?
>> As you say there should be 0 difference in the work the DD has to
>> do. The only difference is what name to put on it.
>
> Again, if that is all the difference there is to it, then that
> difference is meaningless.
>
> [...]
>> > Are sponsored NMUs allowed? They are allowed in the sense that there's
>> > nothing in place to prevent them. But I don't see any reason why we
>> > would want to encourage the practice.
>>
>> So how would I source NMU for example amiga-fdisk? Or get any m68k
>> binary-only upload into the archive?
>
> You should generally talk to an m68k porter (although this could be one
> of those rare exceptions where it could indeed be appropriate to get a
> sponsored NMU).
>
> That said, I don't think Steve was talking about binary-only NMU's, or
> NMU's of architecture-specific packages.
He didn't exclude any of them and its excatly those rare exceptions
where a sponsored NMU would make sense that get hurt by disalowing
them on principle. All DDs I know don't sponsor or NMU lightly and
sponsoring an NMU is even more rare.
I allways found that encouraging for Debian in general even if it
personally anoyed me at the same time by making fixing things
harder. I want it to be hard for others so I have to live with it
being hard too. But to disalow the option alltogether or
discourage them even further?
MfG
Goswin
Reply to: