RC bug fixing + NMU = Fun 2010-08-01, Davis Auditorium * do you have NMU (campaign) experiences? good or bad ones? * advertising NMU campaign: useful or just SPAM? * is the goal of ``more collaborative'' RC-fix worthwhile? * how can we motivate people to do more NMUs? * (how) should we communicate about NMU campaigns? * are current NMU rules (devref §5.11.1) good enough? is LowThresholdNMU useful anymore? * do we need an ``NMU'' equivalent for package removals? * provocation: as an NMU-er, is Maintainer a feature or a bug? Experiences: tmancill: differences between packages of active vs. inactive maintainers which changes are appropriate for NMUs? don: unmaintained packages --> MIA or RM or QA (RM often hard to decide: is someone still using that pkg?, there is popcon to at least give an impression) (if no one is maintaining it, then removal is sometimes better than being unmaintained) marks: exclusivity bad, but contact point necessay jeremiah: teams (pkg-perl) works, collabaration, share responsibility maxy: Its a nice feature to have an ultimate maintainer (or group), to rely on fixing problems in the long run, specially in large packages. But, there is a number of packages, that having no maintainer would actually help them and the user. Q : How many NMU packages installed on zack's system ? ???: How many NMU packages do we have now in the Archive ? About 5% in an example system (how about sharign the script that produced that?) aptitude search '~V.*nmu*' | wc -l shows 67, not sure how accurate About 3.6% on an other Debian mixed system. gaudenz: is anyone using the LowNMUThreshold list (http://wiki.debian.org/LowThresholdNmu) ? -- a handful of people raise their hands "NMU" for removals? RoQA <-> who feels entitled to do this (no experience in QA work) bubulle: LowThresholdNMU: outdated, needs online access, ... if we want something then _in_ the package (switch for dput) Sylvestre: NMUs <-> VCS? VCSes not relevant at the moment. do we need something special? for VCS-users commits might be convenient Q: are you responsible for bugs in packages after NMU? automation? "bts subscribe" "pts-subscribe" commands (devscripts) lucas: NMU process is quite simple, checking VCSes would make it more complex, maintainer's responsibility to integrate the patch finding NMU-able candidates is not always easy? http://udd.debian.org/cgi-bin/rcbugs.cgi http://bts.turmzimmer.net/details.php?bydist=sid&sortby=packages&ignhinted=on&ignclaimed=on&ignnew=on&ignsec=on&ignpending=on&igncontrib=on&ignnonfree=on&ignbritney=on&ignotherfixed=on&fullcomment=on&new=7&refresh=1800 ^ http://tinyurl.com/36uyhd4 Interesting stats from UDD about "packages maintained with NMUs": http://udd.debian.org/cgi-bin/bapase.cgi?t=nmu bubulle: experience: NMUs are welcomed in any area. good communication crucial. (first email is the most important) pabs: experience: I stopped doing NMUs and especially QA uploads because I found they aren't useful to Debian since many of the packages I worked on were just removed from the archive some months afterwards. bubulle: experience (bis). Even when such things happened, Debian benefited from it as I improved my own skills and knowledge while doing that..:-) rules: devref 5.1.11 [all NMUs allowed with DELAYED/10] Suggestion : Add comments on policy preferred by the maintainer in README.Source ? (too late) Question : How to help non-maintainers/DD to NMU ? still interested maybe build a team of NMU sponsors,but that's already done elsewhere in some way --> send patch to BTS, there are people looking at RC bugs with patches General consensus among people who shared their experiences during the BoF: - NMU are nowadays generally, albeit not in all cases, *welcome* by package maintainers - that is even more so when fixing RC bugs, but also when other fixes are provided - it seems that NMU can become a way of collaboration among maintainer and non-maintainer when the maintainer is busy or otherwise does not have enough time to care about long outstanding issues - current NMU rules (devref §5.11.1) are conservative and generally enough to avoid flames when followed properly; nevertheless, they allow quite some deal of collaboration