Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
On Sat, 31 May 2008 09:13:43 +0200, Lucas Nussbaum
<lucas@lucas-nussbaum.net> said:
> On 30/05/08 at 17:28 -0500, Manoj Srivastava wrote:
>> For the record, I don't think that we should remove the language
>> about informing the maintainer with a mail message; and no, I don't
>> think we quite have a consensus on this yet.
> The DEP currently addresses communication like that:
> When doing an NMU, you must always send a patch with the differences
> between the current package and your NMU to the BTS. If the bug you
> are fixing isn't reported yet, you must do that as well.
> I have several questions about the requirement for communication that
> you want to add:
> - Do you want to require two-way communication?
There should be some time for a response to come in, but I don't
think I want the NMU to have to wait on the maintainer. But apart from
the patch, there should be a clear indication of an intent to NMU.
> - If the maintainer doesn't answer, how much time should the NMUer
> wait for the maintainer, in your opinion?
I think the maintainer should be given a "reasonable" time to respond,
for some value of "reasonable". All this also depends on whether the
maintainer is active or MIA, and how sever the bug is, and how complex
the fix would be.
You are aiming for not lower the enthusiasm of the NMU'er by
adding delays, but I think we should also be looking at quality of
NMU's, and consulting and cooperating with the maintainer, who probably
has more experience with the package, rather than just getting the NMU
in.
Perhaps my experience is soured by a recent pointless
*sponsored* NMU to one of my packages (admittedly for a RC bug), with
no mail, no patch to the BTS, and one which failed to fix the problem
(so there was no testing done, faugh).
> - Are the delays that are strongly recommended in the DEP really too
> short, in your opinion?
I think so. When I have NMU'd a package, it has been with a lot
of thought, consulting with the maintainer, offering to help, and then
it still took a week or so to familiarize myself with the package to do
a goods job of testing. And then I was fully subscribed to the package,
and felt responsible for any bug opened until the next upload.
I think that is the right option; hurrying changes into the
archive for "enthusiasm" does not feel right.
The activity level of the maintainer, th degree of familiarity
with the package by the NMUer. the complexity of the bug/solution,
should also be factored in. Even if we can not give a numerical value
to the effect these have, we can add language that says that the NMUer
should take those factors in consideration before deciding to pitch
right in or not.
> The current wording requires a notification (by sending a mail to the
> BTS). I don't think that it's a good idea to additionally require that
> this mail should be sent to the maintainer's private email address,
> because that doesn't work well with co-maintainance.
A mail with an intent-NMU made clear would work, I think. Not
just a patch;
> The current wording doesn't require the NMUer to wait for an
> acknowledgement. Instead, it strongly recommends to give some time to
> the maintainer, which doesn't make a big difference ...
I think I would state it that the maintainer must be given time
to respond, but there can be extenuating circumstances (security fixes,
etc), and the severity of the bug and the simplicity of the fix can
have the window slide shorter or wider.
The bottom line, of course, is the quality of the distribution;
and the trade off between getting fixes in, versus getting the fixes in
vetted by someone experienced with the package -- and weighing in
whether the NMUer has experience with the are or not. (joeyh can NMU my
packages any time, with or without any notice; the people who NMU'd my
package recently should refrain from touching my packages until they
get a response from me).
manoj
Not everything is Black or White
--
A child miseducated is a child lost. -- John F. Kennedy
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: