On Mon, Jun 02, 2008 at 01:12:43PM +0200, Frans Pop wrote:
> On Monday 02 June 2008, Bas Wijnen wrote:
> > 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").
>
> The difference is that now the maintainer is _forced_ to react before the
> package reaches the end of the queue,
Where "react" is "send a mail to the BTS". If the maintainer can't
even do that, then with the current rules, the NMUer can upload to
DELAYED anyway. Are you seriously saying that you want to require the
NMUer to not automate his waiting? What if I send to the patch to the
BTS and upload to DELAYED/11, then I wait 4 days and then (unless there
was a reply) I tell you that the upload is now in DELAYED/7. Would that
be better than saying immediately that it's in DELAYED/11?
> so basically you are forcing him to work on this particular issue
> while he may have other priorities. That is not right.
Sending a mail to the BTS isn't that much work, and it should be done by
a responsible maintainer anyway...
> You are also uploading a patch that the maintainer may never have had the
> chance to review and comment on as the patch may not have been in the
> original BR.
But I'm not uploading it to unstable! I'm scheduling it for upload,
giving you all the time you need to look at it. If there's even a
detail which needs to be looked into, I can simply remove it from the
queue.
> > 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.
>
> Which assumes that the NMUer is available to do so, which is not
> guaranteed by the DEP.
The DEP is in no position to guarantee such things, but it does say:
The DELAYED queue should not be used to put additional pressure
on the maintainer. In particular, it's important that you are
available to cancel or delay the upload before the delay expires
(the maintainer cannot cancel the upload himself).
As I wrote before, I don't want to change this.
> > 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.
>
> I do and will continue to do so. The NMUer should not use DELAYED just
> because "*he* prefers to work that way",
Suppose I like to automate this waiting, and will be available to cancel
the upload. It is appearantly not acceptable for you if I use DELAYED
and tell you about it. Is it acceptable if I don't tell, as I wrote
above? You can check the queue, of course. Would it be more acceptable
if I implement my own delayed queue and tell nobody about it? Is it
acceptable if I put the delay in my PDA so it notifies me when it
expires, or do you feel strongly that I must remember it without any
help?
> but only he is convinced *after checking the policy recommendations
> for NMUs* that it "is a suitable way to deal with that particular BR
> for that particular package".
There should be policies on how to communicate and when to upload to
unstable, not about which technical tools are acceptable to use in
following these policies.
> > No, I don't, I agree with you that this would be unacceptable.
>
> Right, and that is where our opinions _do_ differ fundamentally.
You don't agree that I agree with you?
If this mail hasn't made you reconsider, please tell me what you think I
think, because I think I think something else. ;-)
Thanks,
Bas
--
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