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

Re: Requests for sponsors to upload NMUs

On Wed, 2008-03-05 at 12:37 +0000, Sune Vuorela wrote:
> On 2008-03-05, Neil Williams <codehelp@debian.org> wrote:
> >> of course is changing SONAMEs in a NMU appropriate if it is appropriate.
> >
> > That equates to a hostile hijacking. If the package is orphaned or if
> No it don't. it is just bugfixing. If it requires binary incompatible
> changes to fix it, of course the SONAME should be changed as well. Else
> you introduce new bugs.

Such intrusive "fixes" should not be done without at least trying to
contact the maintainer. Debian has set rules for how packages may or may
not be modified by people other than the maintainer and it does not
matter if you see it as "just bug fixing" - you need to follow the NMU
rules and that means not making intrusive changes. That path leads to

If this is to fix an RC bug, then yes, a SONAME might need changing but
this should not be done without consensus or without very good cause. At
the very least, contact debian-release for advice before changing a
SONAME in an NMU close to a release freeze. Do *not* change a SONAME in
an NMU merely on a lintian warning/error.

The Lenny release is in six months - it doesn't help anyone to make an
unnecessary SONAME bump at this time. That causes more bugs, not less.

> > the maintainer is MIA and the package can be orphaned beforehand, fine
> > (but then it's no longer an NMU, it's a QA upload). Changing a SONAME is
> > *not* acceptable in an NMU without permission from the maintainer. It is
> > an especially bad idea when doing NMU's as part of a release bug
> You seem to be living in perfect-world where maintainers are always
> reachable.

Or just busy. Every NMU must give the maintainer a chance to fix the
problem themselves. The zero-day BSP only applies if the RC bug has
already been open for more than 7 days, specifically to allow time for
the maintainer to fix the problem themselves.

NMUs should not be rushed or overly intrusive and should not include
changes that are more than "just bugfixing".

> MIA-process && orphaning is too slow for bugfixing.  This isn't about
> anything else than bugfixing.

Not true. These are not your own packages, these are packages under the
care of someone else. Until you know that the maintainer is MIA, you
MUST allow time for the maintainer to supply a fix. The RC BSP states 7
days for this time, absolute minimum. Before that time, yes, feel free
to comment on the bug report, add info, suggest a patch etc. but an NMU
should not be done, even under zero day BSP release party rules, until
the maintainer has had some time to view the problem.

Other changes should use the existing NMU rules because, by definition,
a non-RC NMU is not urgent.

If all the requests for sponsors for NMUs here had been exclusively
about bug fixing and nothing else, I wouldn't be spending time on this
thread. I worry that too many requests for sponsors for NMUs here were
about everything *except* bug fixing and that sponsors were asking for
NMUs to make changes that were completely stylistic or solely to shut up
lintian. That is not the purpose of an NMU.

By all means lets keep NMUs for bug fixing - I like that idea, that is
what people expect from an NMU.

> >> Sponsors, keep up your good work.  If the changes are big, please
> >> consider DELAYED/something though.
> >
> > That's worse! There is a day NMU bug squashing party in effect so there
> > is no point uploading to the delayed queue. Just don't make hostile or
> > intrusive changes in an NMU. Stick to the NMU rules.
> fix bugs. Don't make debian the distribution where bugfixing other
> packages is forbidden.  We need better packages. don't stop people
> working for this. With delayed/7, you still have 7 days to react.

That is not how the BSP works. The RC bug must be open for 7 days, then
if the maintainer has not been able to fix it, a zero day NMU can be
done - not before. Who knows the package best - you or the regular

Yes, fix known bugs but don't delay the RC bugs just to fix less
important ones. That's perverse.

In those 7 days, help the maintainer, offer ideas but don't go trampling
over packages until the maintainer has had a chance to fix the issue
themselves. If nothing happens after 7 days, don't delay any further, go
for a zero day NMU to close the RC bug. If some other bugs can be fixed
too, that's fine but don't go after non-bugs like lintian errors.

> > An NMU is not a normal upload. Everyone doing NMU's *must* work with the
> > current maintainer *or* the MIA process.
> If the current maintainer is busy with real life, that is not possible.
> MIA-process takes long time. 

It doesn't take long to check MIA status once the process has completed
(as was the case for the original package that started this).

Yes, the full MIA process can take a long time but the maintainer must
still be given a chance. You cannot assume that the maintainer is MIA
from day zero and start making QA-type changes. Equally, once a
maintainer is known to be MIA, take the opportunity to get the package
adopted or transferred to Debian-QA so that other issues can be fixed.

> > Do not delay RC fixes by adding unnecessary cleanup changes.
> >
> > Do not delay RC fixes by implementing a patch system if the package does
> > not use one.
> >
> > Do not delay RC fixes just to remove a few lintian errors or warnings.
> Please fix bugs.

Yes, but not at any cost. Follow the NMU rules, ensure all issues to be
resolved in the NMU are in the BTS, ensure you commit a full patch to
the BTS for the relevant bugs in advance of the NMU. Ensure that the
changes made are as clean and minimal as possible.

All I'm saying here is that sponsors should not expect NMUs to fix the
full range of issues that would normally be essential to fix for an
upload to NEW or for an upload of a package already maintained by the
person requesting sponsorship.

lintian errors and warnings are explicitly *off-topic* for an NMU,
unless directly related to the RC bug. Stylistic changes like commented
out lines and manpage cleanups are completely off topic for an NMU. The
only time to mess with a manpage in an NMU is for DFSG compliance.

Can we agree that these tasks should *not* be done in an NMU *unless*
directly related to the RC bug? :

1. SONAME changes merely to shut up lintian - i.e. where the RC bug has
no need to change the SONAME.
2. removing commented out lines in debian/rules
3. Implementing dpatch or quilt for a package that does not use it
4. tidying up manpages
5. Changing the build system to/from CDBS/dpkg/dbs/foo
6. other lintian errors or warnings

lintian errors and comments in debian/rules are *not* bugs. I'm not
against fixing bugs that have been properly filed in the BTS and which
have a real effect on user experience but general package cleanups and
lintian fixes do not come under that heading and are not appropriate for
an NMU.

There is a big difference between bug-fixing and QA. NMUs are for fixing
bugs, not stylistic changes within packages or keeping up with lintian.

> > Keep the NMU clean and make sure the entire patch is in the BTS before
> > seeking a sponsor or making the upload.
> Of course make it nice, clean, well-documented

Agreed. Let's keep NMUs for bug fixing, not for stylistic changes.


Neil Williams

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

Reply to: