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 chaos. 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 maintainer? 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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part