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
releases.
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.
Cheers.
--
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