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
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).
[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.
> 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.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature