On Mon, Jun 02, 2008 at 11:01:00AM +0200, Frans Pop wrote:
> On Monday 02 June 2008, Bas Wijnen wrote:
> > While I agree with this principle, I have one comment: IMO posting a
> > patch (with explanation of what it fixes and why, and that an NMU to
> > DELAYED has been uploaded) to the BTS is an appropriate way to notify
> > the maintainer.
>
> Right. And this is where we fundamentally disagree.
I'm not so sure about that, after reading your last mail. :-)
> > I find this important for fixing mass-filed-bugs. They're all similar,
> > the solutions probably are as well, and it would be too much (IMO)
> > overhead to have to check who is maintaining the package.
>
> I have no real problem with what you suggest in _this_ use case, and the
> changes that Lucas has made to the DEP do _not_ prevent doing this.
No, the DEP including those changes doesn't prevent it; but it does use
text which suggests that it's not the right thing to do.
> The only thing the changes are intended to do is to make the NMUer think
> twice about doing a direct NMU without doing the "normal" thing of
> submitting the patch in the BTS
Let's make it a bit more concrete; N is potential NMUer, M is
maintainer, t is time in days:
t=0: N reports a bug.
t=4: there was no response from M, N uploads NMU to DELAYED/7.
t=8: M uploads a better patch himself.
or
t=0: N reports a bug.
t=4: there was no response from M, N uploads NMU to DELAYED/7.
t=8: M tells N that he wants to fix this himself, but needs time, so the
NMU should be cancelled (or he does it himself, I didn't hear any
objection to making this possible).
t=?: M uploads his fix.
or
t=0: N reports a bug and uploads NMU to DELAYED/11
t=8: same as above.
What is the difference for the maintainer between these? Not the time
required for M; in all cases, the most M needs to do to prevent the NMU
from happening is writing a mail to N (and the BTS). The only
difference is what to say ("please cancel the NMU" or "please do not
upload the NMU").
In other words, the difference is only on the NMUer's part. If it is
useful in some cases to just upload to DELAYED and not wait for a
response from the maintainer (but react anyway if it comes, of course),
I don't see any reason to require justification for that. It's only his
own problem, after all.
It's good to suggest (or even recommend) to check with the maintainer
before going through the trouble of preparing an NMU. But if people
feel that preparing the NMU is easy, why stop them? The suggested
procedure will inform the maintainer the usual way, and he has all the
time to say "please wait" in case that is needed. If he doesn't even
have time to do that, then the package is indeed a good candidate for an
NMU IMO.
> and giving the maintainer a chance to respond without forcing his hand
> and forcing him to reorder his priorities by doing a simultaneous
> upload to DELAYED.
If there's no upload to DELAYED, he only needs to say he saw the bug,
and that he's working on it. If there is an upload, he only needs to
say he'll work on the bug, and that the NMU should be cancelled. No
reordering of priorities is required.
> > This is only about bugs which have had the "intent to NMU" in the BTS
> > for some time before the upload hits unstable. I explicitly do want to
> > allow (and not discourage) uploading to DELAYED at the same time as
> > reporting the bug in the BTS, even for active teams.
>
> I do, and if you are not willing to compromise on this I doubt there is
> ever going to be consensus on this DEP. Not for all cases, but I see no
> reason why that should become the "normal" practice for *all* packages
> and for all *bug* severities and for *all* types of bugs.
No, not normal practice indeed. I agree with you that in many cases it
is better to just send a patch. But I don't see a problem with
uploading to DELAYED (with sufficiently high delay), if the NMUer
prefers it.
> Consider again Debian Installer. D-I is native code. This means that every
> upload is effectively a new upstream release. What you are proposing is
> to let random people do upstream releases without first discussing their
> changes with the upstream maintainer.
I am not suggesting that people should be doing uploads to unstable, I'm
only saying that they can send a patch to the BTS and DELAYED if they
want. Given that the D-I team is active, it should be no problem to
have at least one person saying "thanks, we'll solve it our own way".
> My second main objection was this <200805312102.18976.elendil@planet.nl>:
> ! The DEP should not be a licence to avoid entering into a discussion with
> ! the maintainer of a package, or to pre-empt him.
>
> From my PoV your standpoint is that you _do_ want to give developers that
> licence and for me that is unacceptable.
No, I don't, I agree with you that this would be unacceptable. If the
maintainer says "no", then the NMUer should need the technical committee
to override that, nothing less. I just want to have written down that
it is acceptable to use the DELAYED queue to delay things which may or
may not need to reach unstable. If someone wants to upload things there
which he expects to cancel later, then I don't want to stop him. It's a
technical system, and I don't want to put limits on how to use it. It's
the result that counts, and here the result is "communication with
maintainer (which is independent)" and "upload to unstable only after
discussion with and agreement from maintainer or non-response for
sufficiently long time".
The DEP already says that the DELAYED queue must not be used to put
pressure on the maintainer. I don't want to weaken that point.
> To be totally clear: I do think the policy you are proposing makes sense
> for some cases and should be possible. But there are also cases where the
> current practice of just submitting your patch to the BTS and having the
> maintainer handle the rest of the process should remain the normal
> procedure, and the DEP should reflect this.
I agree that it should be normal, and that the DEP should reflect this.
The DEP currently suggests[1] that you always need to wait for response
from the maintainer, and are not allowed to use technical means such as
the DELAYED queue to automate certain paths. IMO using a technical
means is always acceptable if there is no difference in the result.
After a "bug report + upload to DELAYED", I would expect discussion with
the maintainer. This discussion is likely either "Fine, go ahead" or
"I'll upload it myself". If other responses are likely, the direct
upload to DELAYED is not useful. But that's the NMUer's problem, since
it still doesn't change anything for the maintainer.
Thanks,
Bas
[1] This suggestion is my reading. Strictly speaking, it's not written
there.
--
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
Attachment:
signature.asc
Description: Digital signature