NMU etiquette (arpwatch package)
(Please CC me on replies as i'm not subscribed to debian-devel) it's been a long time since I've done this, so i'd like to know what the current etiquette is for an NMI. arpwatch has had only sporadic NMU updates since 2004. I've packaged the latest version and applied a bunch of patches from the BTS (all that applied cleanly without conflicting with other patches), and fixed a few other minor bugs. most of these bugs are years old. I'd like to upload this to unstable, but i don't want to maintain the package forever. I've mostly worked on this NMU because I wanted to fix the sprintf for printing MAC addresses (zero-padded with %02x rather than just %x), and decided I may as well fix some of the other outstanding bugs too. probably the only really controversial thing about this NMU is that i've dumped the dbs-based packaging, and just gone with debhelper. I don't have time to learn dbs and have no inclination to do so, either. i like the *idea* of dbs but not the practice (i find it's a pain to work with -- it was easier for me to re-package the latest version of arpwatch from scratch than it was to figure out how dbs works just to make a one-line change for the sprintf problem). given that arpwatch has hardly been touched for the last few years, i'd guess that dbs is putting off other potential NMUs or maybe even an adopter too. anyway, here's the changelog entry: arpwatch (2.1a15-1) unstable; urgency=low * not-so-new upstream release (Closes: #427867) * converted packaging from dbs to debhelper * applied all existing patches from old 2.1a13 package * made bihourly.sh an example, and copied bihourly cron script from 2.1a13 * deleted duplicate errs= line from bihourly (Closes: #321504) * fixed sprintf in ec.c (Closes: #315215) * Applied patch from Sebastian Reichelt sebasti...@gmx.de to initialise interface variable (Closes: #289426) * updated watch file to v3 (Closes: #529097) * applied patch from Sebastian Reichelt to display IP in subject if hostname unknown (Closes: #288994) -- Craig Sanders c...@taz.net.au Tue, 01 Sep 2009 20:00:54 +1000 craig -- craig sanders c...@taz.net.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NMU etiquette (arpwatch package)
Quoting Craig Sanders c...@taz.net.au: (Please CC me on replies as i'm not subscribed to debian-devel) it's been a long time since I've done this, so i'd like to know what the current etiquette is for an NMI. arpwatch has had only sporadic NMU updates since 2004. I've packaged the latest version and applied a bunch of patches from the BTS (all that applied cleanly without conflicting with other patches), and fixed a few other minor bugs. most of these bugs are years old. Looking in the database, Peter Kelemen doesn't seem to have been around for about 2 years. I suspect MIA proceedings need to be started if they haven't been already. Certainly the package needs to be orphaned. Colin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NMU etiquette (arpwatch package)
* Colin Tuckley (col...@debian.org) [20090901 14:32]: Looking in the database, Peter Kelemen doesn't seem to have been around for about 2 years. I suspect MIA proceedings need to be started if they haven't been already. I'm still lurking... Adoption has been tried before and died off. Craig, please go ahead with your NMI now and we'll work out the details later. Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NMU etiquette (arpwatch package)
Hi Craig, On Tue, Sep 01, 2009 at 10:57:30PM +1000, Craig Sanders wrote: (Please CC me on replies as i'm not subscribed to debian-devel) it's been a long time since I've done this, so i'd like to know what the current etiquette is for an NMU. arpwatch has had only sporadic NMU updates since 2004. I've packaged the latest version and applied a bunch of patches from the BTS (all that applied cleanly without conflicting with other patches), and fixed a few other minor bugs. most of these bugs are years old. I'd like to upload this to unstable, but i don't want to maintain the package forever. I've mostly worked on this NMU because I wanted to fix the sprintf for printing MAC addresses (zero-padded with %02x rather than just %x), and decided I may as well fix some of the other outstanding bugs too. probably the only really controversial thing about this NMU is that i've dumped the dbs-based packaging, and just gone with debhelper. I don't have time to learn dbs and have no inclination to do so, either. i like the *idea* of dbs but not the practice (i find it's a pain to work with -- it was easier for me to re-package the latest version of arpwatch from scratch than it was to figure out how dbs works just to make a one-line change for the sprintf problem). given that arpwatch has hardly been touched for the last few years, i'd guess that dbs is putting off other potential NMUs or maybe even an adopter too. (Aside: dbs is a patch management system, and as such is orthogonal to debhelper. Indeed, arpwatch build-depends on debhelper *as well as* dbs.) I'm glad to see that Peter has approved of your NMU proposal, as migrating away from hand-rolled debian/rules files is a goal that I heartily support. However, your original question was one of etiquette, and I don't think that's been addressed in this thread. Yes, replacing the build system of a package in an NMU without the consent of the maintainer is an NMU faux pas. :-) NMUers should limit themselves to changes that directly fix bugs, and steer clear of design decisions regarding the packaging. If some of those design decisions mean no one is willing to NMU the package and the package falls into disrepair as a result, then it's a candidate for orphaning via the QA team processes; but we shouldn't force the issue by replacing a build system we don't like with another that the /maintainer/ may dislike just as much when they come back to the package. Other polite conventions regarding NMUs are spelled out in the developer's reference http://www.debian.org/doc/developers-reference/pkgs.html#nmu. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: NMU etiquette (arpwatch package)
On Tue, Sep 01, 2009 at 09:30:04PM -0700, Steve Langasek wrote: I'm glad to see that Peter has approved of your NMU proposal, as migrating away from hand-rolled debian/rules files is a goal that I heartily support. However, your original question was one of etiquette, and I don't think that's been addressed in this thread. Yes, replacing the build system of a package in an NMU without the consent of the maintainer is an NMU faux pas. :-) yep, i figured that. which is why i made a point of highlighting the fact that i'd done it. NMUers should limit themselves to changes that directly fix bugs, and steer clear of design decisions regarding the packaging. my initial intent was just to fix the MAC address sprintf for myself, and use it on my own systems. then i looked at the dbs packaging for a while and the amount of work involved in just figuring out how it worked was too much, so i decided to just repackage the latest version for myself. and, of course, i kept all the previous patches and changes from the previous package. and then i fixed some of the other bug reports. when i'd done all that i figured it would be a shame to let that work go to waste on just my own systems and decided to find out about current NMU practices. arpwatch is quite useful for those who need it and doesn't really have any newer or better-maintained alternatives that do the same job. so, it's kind of an accidental NMU. i started off just wanting to fix a very minor problem for myself and a few hours later ended up with a complete new package. anyway, i'll be testing my arpwatch package on my own boxes for a while and, if i haven't introduced any new bugs, i'll upload it in a few days. If some of those design decisions mean no one is willing to NMU the package and the package falls into disrepair as a result, then it's a candidate for orphaning via the QA team processes; but we shouldn't force the issue by replacing a build system we don't like with another that the /maintainer/ may dislike just as much when they come back to the package. apart from occasional NMU over the last 5 years, arpwatch seems abandoned. IMO a working, updated, bug-fixed package is better than just letting it drop out of debian entirely - especially when it does a unique and useful job that no other package does. but then, i've never been precious about ownership of packages - mine or anyone else's. IMO, getting stuff done is far more important than WHO does it. and if the package's official maintainer doesn't like what was done in an NMU they can always ignore it or re-do it in their preferred style when they get around to it. but if Peter K had said not to upload it, i'd keep it as a private package, or just put it up on my web site for anyone else to download outside of debian. i may have misread it but Peter seemed to hint that he'd like someone to adopt arpwatch...hopefully the new form of the package will make it more appealing (or less unappealing) to someone. Other polite conventions regarding NMUs are spelled out in the developer's reference http://www.debian.org/doc/developers-reference/pkgs.html#nmu. thanks. craig -- craig sanders c...@taz.net.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
