re: *UNAPPROVED* dpkg nmu
On Sat, 28 Feb 2004, Scott James Remnant wrote:
> On Sat, 2004-02-28 at 02:53, Adam Heath wrote:
>
> > Why did you nmu dpkg? I see no mail from you on the mailing list about
> > preparing an nmu.
> >
> Because the package had Release-Critical bugs open against it which, for
> whatever reason, had not been acted upon by the maintainers. All of
> these were over a month old.
That's no reason to do an announced nmu. You announce an nmu by sending mail
to the maintainer, and the maintainer is this list.
> For such an important package to be in this state right before a release
> is not a good situation to be in.
Well, sorry for having a real life.
If you want to help with dpkg, you don't go and subvert the existing
maintainers, nor existing policy.
> You may have perfectly valid reasons for not being able to work on dpkg
> at the moment, I'm not contesting that. However these reasons should
> not stop *anyone else* working on dpkg.
There's nothing stopping you working on dpkg. Send patches, tag bugs, retitle
bugs(pseudo tagging). Post bug summaries to the list. Show the maintainers
you are worthy of working on the package. That's what I did years ago.
> You appear to have taken the stance that dpkg is somehow 'sacred' and
> not to be touched by the hands of mere mortals not yet blessed; when
> instead you should be welcoming the fact there's people out there who
> have suddenly got it into their minds to triage, test and fix the
> (current) 663 open bugs against it.
No, I'm saying policy and procedure should be followed. This did not happen.
> And, to put it bluntly, there is a long and honourable history of NMUing
> dpkg.
But those people already had approval, and didn't do it behind the scenes.
> > I stopped receiving @doogie.org mail yesterday afternoon(forgot about my
> > domain). If you sent mail after that, then you didn't wait long enough. And,
> > besides, I'm not the maintainer of dpkg; this list is.
> >
> > I see you sent me a *private* mail about. That is not how you discuss dpkg.
> > I will not participate in any discussion about dpkg that isn't public. If you
> > want to discuss dpkg, then resend your mail publically. I will have *none*
> > of these backdoor meetings.
> >
> It was hardly a backdoor meeting, it has been publically announced and
> discussed. Your co-maintainer certainly knew about it, but
> unfortunately couldn't attend at the last minute and instead provided
> those asked to attend (including myself) with points to start useful
> discussion.
Mail sent to me privately is not public.
> And the single, greatest point to come out of this meeting was that dpkg
> is, quite frankly, in a terrible state and that it obviously needed
> people to work on it.
So you start out small, making it easier for the existing maintainers to do
the work. You don't skip all those steps and upload the package.
When I started pursuing joining the dpkg team, I sent patch after patch to
this list, fixing various bugs in dpkg. Wichert eventually added me to cvs.
I then started fixing bugs in cvs directly. It was a long time before I
actually did my own upload.
> Of course, you should know all of this already because I mailed a full
> and detailed summary of everything we discussed to you and Wichert (the
> contents of the dpkg Uploaders: field). It made specific mention of our
> intent to upload a version of dpkg to fix the release-critical bugs.
Uploaders != Maintainers. Are you really this dense?
> I mailed it to you personally to ensure you read it, as you haven't been
> active on debian-dpkg for at least a month and Wichert hasn't in the
> past 6 months! For the audience out there, this includes any bug
> activity for dpkg.
Well, the past month was bad timing. As I've said, my father passed away Feb.
5. I *have* been reading -dpkg. Your mail, that was sent to me privately
last monday, was when I was back to work. I have been reading -dpkg all week.
> That mail isn't private, if anyone out there is interested in what we
> talked about I'll be happy to open it to a wider audience, I just
> thought you might like to talk about it first. Hell, if those people
> agree with us, and want to help out our effort to fix dpkg bugs, that'd
> be great.
If it wasn't private, then you shouldn't have sent it privately.
> I'd actually like to bring up a point of confusion here as well. You
> say that the upload was "unapproved" (in bold capitals, no less);
> unapproved by whom? If your statement above that the debian-dpkg list
> are the current maintainers of dpkg, then anyone on that list could've
> approved it, including myself?
>
> Alternatively, you and Wichert are the dpkg maintainers, in which case I
> did send that mail to the right place, and the problem is that you
> didn't read it; for which I cannot be blamed.
The contents of the upload weren't approved. We had no idea what the exact
contents of that upload would contain. No single diff was ever sent first,
just a mail to -changes, and mails from katie.
> > When preparing an nmu, one should do the changes, create a diff, file a bug
> > with the diff, wait, then upload. These steps *were not done*.
> >
> I'm so going to hate myself for this, but I'm going to quote policy at
> you:
>
> Also, after doing an NMU, you have to open a new bug and include a
> patch showing all the changes you have made. Alternatively you can
> send that information to the existing bugs that are fixed by your NMU.
>
> -- 5.11.4.3. Source NMUs and the Bug Tracking System
>
> The bugs fixed by this NMU were *ALREADY* marked with the [patch] tag,
> except one which was a trivial one line fix that was already fixed on
> CVS HEAD.
>
> I believe, in of itself, that this would've sufficed for policy. I went
> further than this, and updated each bug with the individual patch
> applied, including ChangeLog entry, for easier analysis.
Any upload involes more than just applying patches, or fixing bugs that have
no patch. There are other changes that must occur(like changes to the
changelog headers, version-nr kinda stuff, other misc. things), that have no
reason to be mailed to individual bugs.
> I leave it to the audience whether an NMU to fix Release Critical bugs
> that had been ignored by the maintainers is correct, or not. Especially
> in the pre-release state we should all be in by now.
As for that security bug, I had read that, and agreed it was a problem. I
hadn't given time to thing about the implications of a fix, whatever it is.
Now you've gone and done it, and I still don't know if I agree with it.
> > Developers: do not install dpkg 1.10.18.1, until such time as the code has
> > been auditted.
> >
> Put your toys back in your pram, Adam; now you're just being childish.
Follow procedure then. All I ask is that people do the same thing I've done,
when it comes to dpkg. I ask nothing more.
> Do you really believe so poorly of your fellow developers that any
> attempt to fix bugs is an attempt to compromise security?
No, just those who can't do things like everyone else.
> Those people who helped produce this NMU *also* maintain (amongst other
> packages): build-essential, base-passwd, openssh, apache, apache2,
> mailman, man-db, binfmt-support, libtool & groff.
I don't care what the others maintained; it has no bearing on whether they can
do things for dpkg. I'll accept anyone who can prove they can handle dpkg, no
matter how much or little they have done elsewhere.
> To be honest, I'm quite offended and indeed, worried, that you would
> suggest such a thing.
plonk.
> For those who haven't fled in terror, and are curious, I've attached the
> complete diff (before autoconfery) for auditing.
>
> I await to be carted away in handcuffs. In fact, I demand it.
> Handcuffs are hot!
It's not that I consider dpkg sacred, and not to be touched; debian considers
it sacred. I have done plenty of botched uploads of dpkg in the past, so all
uploads need to be heavily scrutinized. I'm still not perfect in this regard.
New people to the dpkg round table need to take extra care, and not subvert
standard procedure.
Reply to: