On Sun, Jul 30, 2006 at 10:04:09AM -0500, Manoj Srivastava wrote:
> I think I would prefer:
> > 1. Create patch
> > 2. Send patch to BTS (with intent to NMU notice)
> 3. Give time for maintainer to respond
> > 4. Upload to N-day delayed queue (where N can be determined based on
> > severity of bug, importance of package, proximity to a freeze,
> > etc)
> N can be less than 7, compensating for the time spent looking
> for maintainer input.
The point of the delayed queue is so that you don't have to remember
to act if the maintainer doesn't respond. That can be pretty difficult,
it's easy to remember to do something if the maintainer *does* respond --
you get a cue in the form of the maintainer responding; but when they
don't, you have to remember spontaneously yourself, even though by that
time you may have any number of other things distracting you.
For NMUers, the ideal workflow is:
(a) find a problem
(b) fix it
(c) set the process in motion to have that fix be in Debian
(upload to DELAYED, make sure the bug report is up to date,
mail the maintainer directly, subscribe to the PTS, etc)
(d) forget about it until something happens
(e) if the maintainer responds, deal with that as appropriate (eg,
by obsoleting the DELAYED upload with an improved patch, etc)
(f) if the DELAYED upload is accepted, _and_ bugs are filed against it,
fix them
The first set, (a)-(d), can all be done in a single session without any
coordination, and the other two bits of work need to be done in response
to given actions only, rather than needing a specific time set aside
for them in advance.
And if the maintainer's response is to include the patch (or a better
one) and upload it, the DELAYED upload will be REJECTed, and it will be
as if there was never a DELAYED upload in the first place.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature