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

Re: what to do is maintainer is lacking? (was: wine-unstable in Debian)

On Wed, Apr 18, 2012 at 11:28:33AM -0400, Chris Knadle wrote:
> Thanks -- however after reading it, my opinion of NMUs has not changed, except 
> for lowering of severity level.  [And realistically at least in the general 
> case I don't think another DD is going to do an NMU if a bug is not RC.]
> The way section 5.11 is written, it implies NMUs are for bug fixes only.  It 
> literally states "Fixing cosmetic issues or changing the packaging style in 
> NMUs is discouraged."  Nowhere in the section is it implied that NMUs can be 
> used to upload new versions of software, so I still think that's not what 
> they're for.  :-/  [Please correct me if you believe this is not the case.]

I do believe that there should be no preclusion, a priori, on doing NMU
for any kind of bugs, including bugs that request packaging new upstream

More generally, I think the key to make NMU work properly is not to be
found in overly precise rules, but rather in guidelines that explain the
spirit of them (which I think are properly explained in the devref
section I've mentioned). The point of NMUs is *helping* a maintainer
which, for different reasons, is temporarily unable to fix specific
issues in their packages. If the NMU-er keeps that principle in mind,
everything else descends more or less naturally.

1) as NMU-ers are, at least as first glance, helping one off they should
  make it easy to integrate their work by the legitimate maintainers
  when they come back -> hence the commonsense requirement of minimizing
  unneeded changes (which, BTW, is nothing special --- it is common
  practice in Free Software when sending patches or committing to VCSs)

  (this point is clearly made more difficult by the specificities of the
  "new upstream release" case, and I think what Michael has proposed to
  do in the buglog we have been discussing in this thread is a pretty
  decent solution to that)

2) as there might be disagreement on the notion of whether the maintainer
  actually needs help on not, the DELAYED queue exists to give time to
  the maintainer to react and has the beneficial side-effect of allowing
  for independent reviews of the NMU diff

3) as NMU-ers introduce changes that (by definition of NMU) are not
  necessarily vetted by the legitimate maintainers, NMU-ers should keep
  an eye on the package they've NMU-ed rather than forgetting about it
  after the upload -> hence the suggestion of subscribing to PTS
  notifications for the NMU-ed package

Years ago, I've been applying the above commonsense principles while
performing several NMUs and I've never received harsh replies in
response. That experience has convinced me that properly done NMU are
just welcome and that to properly do NMU you just need to keep in mind
that the goal is helping the maintainer and use commonsense.

Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

Attachment: signature.asc
Description: Digital signature

Reply to: