Re: DEP1: how to do an NMU
Le Sat, May 31, 2008 at 06:08:56PM +0200, Lucas Nussbaum a écrit :
> On 01/06/08 at 00:22 +0900, Charles Plessy wrote:
> >
> > 5.11.1 When and how to do an NMU
> >
> > I propose to add "NMUs are usually not appropriate for team-maintained
> > packages. Consider sending a patch to the BTS instead." to the bullet
> > list.
>
> It really depends on the team. There are small teams where all members
> might become unresponsive at the same time. I don't think that we should
> special-case this.
This is sort of true in the sense that sending a patch is anyway the
preferred way to help. I hope that people will use their common sense:
if the maintainer of a package has "Team" in its name, if the repository
in which the package is stored has frequent commits, and if the mailing
list of the team has frequent messages, then the maintainer is active
and therefore patches are the preferred way to help.
Once again: if the goal of the NMU is to help the maintainer, consider
sending a patch instead. If the reason of the NMU is that there is
obstuction or non-reponsivity, consider fixing the Maintainer: field or
asking for the removal of the package.
> > I propose to ask a paragraph saying:
> >
> > "If you do not make your NMU to DELAYED/, you must document your reasons
> > in the BTS."
> >
> > I and others had NMUs on non-RC bugs on team-maintained packages while
> > being active and we are still left to wonder what in our packaging
> > practice was so wrong that it had to be fixed in emergency. Having the
> > reason written in the BTS would help us to improve ourselves.
>
> Can you give a specific example where this happened?
I prefer not: I do not want this discussion focusing on the details of
one particular NMU. This makes things more personnal and heats the
debate, while losing focus on the DEP itself. I really would like to see
the reasons of non-delayed NMUs documented. It is as simple as adding
"(breaks buildds)" or similar comments in the BTS mail. For more
borderline cases, it will bring examples for the next time the
developpers reference will be updated (hopefully not before a few
years).
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: