On Tue, 2008-03-04 at 16:07 +0900, Paul Wise wrote: > On Tue, Mar 4, 2008 at 2:57 PM, Barry deFreese <[EMAIL PROTECTED]> wrote: > > > Here is another one of my way too intrusive NMUs that closes RC bug > > #465633 and bug #400257 as well as quite a bit of package cleanup, > > standards update, etc. > > > > If someone has time to review and/or upload I would appreciate it. > > Package hasn't seen an upload since 2005. > > Neither orange in the archive nor the result of your NMU even work for > zip files (with unzip installed) nor other files where it should work. > >>From strace, it looks like it is acually extracting stuff, but then > deletes the files instead of copying them to the output directory. It > would be nice if this could be fixed too.
Paul, is that realistic for the NMU? This isn't an orphaned package, it
isn't a hijack, this is an NMU to get orange into Lenny.
I've NMU'd one of the packages from the same maintainer recently and
orange is similar in respect that the last upload was over 2 years ago.
Yes, there is a case for MIA but AFAICT that has not been done. There
are a host of other changes that could/should have been made but I did
not do so.
NMU's shouldn't try to fix unreported bugs and shouldn't try to be a QA
upload that tries to close all possible bugs either.
The RC bug against orange is a simple fix and a clean NMU.
Barry, I think it's better to *not* make non-bug related changes in any
NMU. Stick closely to the NMU policy and do not handle NMU preparation
in the same way that you would if it was your package. NMU's are
*minimal* - you make as few changes as are absolutely necessary to fix
the issues described in the RC bug report and if there are other fixes
that are similarly clear for other bugs, outline those changes in the
relevant bug reports. Do not make any changes in an NMU that have no
corresponding bug report.
When sponsoring an NMU, I feel it is important to stick to the task at
hand and leave the maintainer to do the rest. If that means starting the
MIA procedure instead, so be it.
Personally, I am *not* happy to sponsor this NMU for orange until the
package cleanup stuff is reverted (especially removal of commented out
lines in debian/rules) and I do *not* think that concerns about how
orange should or should not behave can be addressed in an NMU that is
primarily intended to get the package into Lenny, doing the same job as
it is in Etch and before. If the package needs to have functionality
'foo', it is a matter for the maintainer and/or upstream, falling back
to the MIA and QA teams where appropriate, not a BSP NMU.
I would omit these changes:
+ * {Source-Version} -> {binary:Version} in -dev package.
+ * Remove unneeded debhelper commands from rules.
+ * Fix minor bashism in rules.
+ * Make clean not ignore errors.
+ * debian/orange.1 - Fix whatis entry for description.
+ * Bump debhelper build-dep and compat to 5.
+ * Bump Standards Version to 3.7.3. (No changes needed).
The manpage change, in particular, is too minor for an NMU IMHO.
These issues are typical of a QA upload and should be done only if the
maintainer is known to be MIA and only after the package has been
orphaned.
--
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
