> > > > 2. Perhaps it would be better to have all of the source code > > changes done through dpatch or quilt. I know this is an NMU and > > being unobtrusive is important, but there are quite a few > > upstream source code changes which I think would be better off > > in a patch system. > > > So why are we doing this now? This is an NMU - minimal changes scenario. > > Barry is not the maintainer for this NMU, why are the rules being > ignored on mentors?
(Specifically, "do not change the build system in an NMU". With the recent controversy about not having patch systems at all, about new format source packages and storing everything in the .diff.gz, I'm surprised that this is even being considered for an NMU, let alone stipulated as a requirement for upload.) 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. 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.) 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? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
