On Wed, 2008-03-05 at 10:57 +0000, Sune Vuorela wrote: > On 2008-03-04, Neil Williams <codehelp@debian.org> wrote: > > Are sponsors going to start recommending changing SONAMEs in an NMU > > next? Adding -dbg packages? Of course not, NMUs are different to typical > > RFS activity. > > 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 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 squashing party because of the transition that follows. Unnecessary transitions must be avoided prior to a release. Adding a patch system is also not acceptable in an NMU. Neither is converting from dpkg to debhelper or CDBS or any other build system, even if, in your opinion, it would help the package overall. > > Having a sponsored upload that is lintian clean is AGoodThing(tm) for an > > ordinary RFS where the maintainer is the one requesting sponsoring. All > > those niceties simply do not apply to an NMU - lintian errors are to be > > preserved in all their ugliness unless specifically part of an existing > > bug report in the BTS *or* relevant to the fix for the RC bug. (And a > > mere lintian error/warning is not a good reason to file a new bug > > either, that's why lintian exists.) > > yeah. let us not improve the package quality in debian. If you are not the maintainer, those changes must be done either in coordination with the maintainer or via the MIA process. There are protocols for making such changes - NMU is *not* one of them. > > Sponsors, can we please stick to the rules for NMUs so that those who > > seek advice here can get clear guidance on what is required? > > 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. An NMU is not a normal upload. Everyone doing NMU's *must* work with the current maintainer *or* the MIA process. 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. Keep the NMU clean and make sure the entire patch is in the BTS before seeking a sponsor or making the upload. -- 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