On Sat, Jul 31, 2010 at 12:34:23PM -0400, Stefano Zacchiroli wrote:
> Hi everybody, it wouldn't be nice to campaign for preparing BoF in
> advance and not doing it for a BoF I've submitted myself! So, if you
> are interested in fixing RC bugs and in SPAM-ing planet about your
> initiatives in that direction, then you're also invited to attend:
>
> RC bug fixing + NMU = Fun
> http://penta.debconf.org/dc10_schedule/events/609.en.html
It looks like that Gobby-based collaborative minutes taking has worked
pretty well for this BoF! It did help to ask Gregor to act as "minute
master", but a lot of other people have contributed in taking
notes. Thanks to everybody who has contributed!
I attach the BoF notes to this post.
I've also uploaded them as an attachment to the event in Penta (although
the public page linked above has not been rebuilt yet).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
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
Attachment:
signature.asc
Description: Digital signature