Re: NMU procedures
Hi!
I'm writing mainly after the experience of doing several (more than
50, I lost count) NMUs in the past weeks. It may be a bit repetitive,
but I hope you find it useful.
On 8/30/06, Dominic Hargreaves <dom@earth.li> wrote:
The problem probably doesn't qualify as more severe than normal by the
stated criteria but is presenting problems. The fix is trivial and is
included as the only substantive change in a new upstream release.
I just wanted to check that an imminent upload of a new version
(0.78-0.1) to the 7-day queue is reasonable. By my reading of the
Developers' reference it is, but thought it was worth sanity-checking.
With these special situations, I usually evaluate them on a case by case basis.
In the case of libtext-wikiformat-perl, it seems that the package (not
only this particular bug) has been inactive for a long while, so I'd
say that you can take the time to do the work, quite safely. It's
improbable that the maintainer is doing it at the same time or that he
would feel bad about your NMU.
When preparing the NMU, try to respect the maintainer in the decisions
that he has made. I.e., if he doesn't use a patch system, you usually
shouldn't add one. However, if he does use a patch system, you should
follow suit and use it, no matter how unfriendly you find it.
Also, give the package as much love as you can, specially when you are
doing a big change, as a new upstream release. Check that things are
in place, and that everything is well done.
State your changes in the changelog, in a clear way (do not give too
verbose explanations, save those for the mail you'll send to the bug).
Check twice that the package builds inside and outside a pbuilder, and
that the generated diff makes sense. Test that it installs, works,
and de-installs well.
Once you are ready, you should send useful info to the bug. In this
case, the most probable thing that would make sense to send is the
.diff.gz and the link to the file that you downloaded and included as
.orig.tar.gz (In other cases, you can use nmudiff, or interdiff, to
only show the changes made to the diff.gz).
In your mail, include any information about the changes that you made
to the packages (what patches you added, what things needed change and
why, etc).
After sending the mail, you can upload. To the delayed queue, as you
stated. 7 days sounds fine.
I've done a LOT of NMUs lately, and I was surprised by the amount of
positive replies that I got. Most maintainers are glad that you spent
time making their package better. That happens when you do it with
love and care for the package.
--
Love,
Marga
Reply to: