[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP1: how to do an NMU

On Saturday 31 May 2008, Lucas Nussbaum wrote:
> So far, you (in <200805301141.02910.elendil@planet.nl> and
> <200805301718.06394.elendil@planet.nl>) and Charles Plessy
> (<20080530100316.GD4794@kunpuu.plessy.org>,
> <20080531152214.GA8808@kunpuu.plessy.org>) raised that concern.

Sure, but Steve Langasek, Manoj and Frank Küster have been voicing what 
are basically the same concerns.

> On the other hand, Bas Wijnen
> (<20080530101631.GA15849@a82-93-13-222.adsl.xs4all.nl>) and I disagreed
> that a special consideration was needed. We can't just blindly add
> every suggestion that people propose, because that would make other
> people unhappy.

Problem is you did not at the same time acknowledge that the concerns 
themselves could be valid and that you were willing to discuss them 
further and thus come to a different solution. This mail does do that.

> I am opposed to forbidding NMUs, or requiring prior ack from
> the maintainer, for some categories of maintainers. If we start listing
> such categories, we will end up with something like:
>  - teams with at least one very active/responsive member, or two
>    active/resposnive members
>  - very active/responsive DDs, unless they are in VAC for more than n
> days That will be totally a PITA to check, and very error-prone. (how
> do you measure activity and responsiveness?)

Fine. I'm only providing examples of cases where I feel NMUs are in 
general not appropriate. A more general rule would be fine with me, as 
long as it does cover the particular case in some way.

> Instead, I'm totally open to emphasizing the fact that if the package
> is maintained by a team or by a known-active DD, the NMUer should
> really try harder to contact the maintainers before proceeding with the
> NMU.


> Phil Hands proposed something in <20080531101718.GE17257@hands.com>:
> > Clearly there are cases where NMUs are inappropriate.  The DEP is
> > currently missing language to make that point clear (at least in my
> > reading of it) perhaps it needs a final clause along the lines of:
> >
> >   This is not a license to perform NMUs thoughtlessly.  If you NMU
> > when it is clear that the maintainers are active and would have
> > acknowledged a patch in a more timely manner, or if you ignore the
> > recommendations of this DEP, or if you do something else that assumes
> > that this is an NMUers charter and that a lawyerly interpretation of
> > some subclause can be used to justify some abusive action, be warned,
> > there is no protection for you here.  You should always be prepared
> > to defend the wisdom of any NMU you perform on its own merits.
> Frans, would adding that paragraph solve your concerns, or can you
> suggest a patch to this paragraph that would solve them?

I think that mentioning in some way that you should be prepared to defend 
a decision to NMU would be very good. The "lawyerly interpretation of 
some subclause" phrase is probably a bit too much :-)

See my second reply to Luk for a more concrete proposal, but I'd be happy 
to see the "be prepared to defend" bit added to that in some way.

> If you started to propose wordings that would suit you, instead of
> waiting for us to propose stuff by mind-reading, that would be a lot
> easier to listen to you.

The thing is that I basically agreed with suggestions (or at least with 
the intentions behind them) from others which were  waved away. That is 
not very motivating for writing other proposals.
IMO you first have to reach agreement on the principle you want to put 
into words when there is such a clear difference; proposing variations on 
the same text is only going to lead to frustration. That is why I started 
presenting use cases in which I feel NMUs to be less appropriate (and 
explaining my reasons in more detail).

Anyway, my reply to Luk contains a fairly concrete proposed text.

From my perspective its your (plural) job as proposers/editors of the DEP 
to put things together though.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: