13:01 okie dokie! 2100UTC. 13:02 do we get the channel's full attention for this, or should we fork off so people can keep talking about blosxom? :) 13:02 I think we're probably cool to stay in here 13:03 if people mind that, they can say so... 13:03 hi 13:03 I'm fine here -- want to learn what I've been doing wrong the past few days, so... :) 13:03 I suspect quite a few people are interested in bug squashing... 13:04 I'm here for the bug squashing tutorial 13:04 just put in the /topic what's going on, and ask people for offtopic things later 13:04 -!- vorlon changed the topic of #debian-women to: "Women in Debian" | Website: http://women.alioth.debian.org/ | Mailing list: http://lists.debian.org/debian-women/ | IRC meeting Jan 16 at 0500 UTC. | RC Bug Squashing Seminar 21:00-01:00 GMT | class is now in session 13:05 ok, welcome to the latest debian-women attempt to subvert the established order. 13:06 :) 13:06 Today we're going to be talking about fixing release-critical bugs. Since release-critical bugs are... release-critical, it is very important to the Debian release process that we find and fix these bugs as they arise. 13:07 So even if you don't succeed in closing an RC bug today, you can feel proud that you're contributing to the release process :) 13:08 Since this is an IRC setting, I'm not overly concerned that the channel remain completely quiet for my monologue; in fact, background noise might make me more comfortable so that I know people are looking at the window ;) If the main thread starts to get drowned out, I'll bang a gavel or something. In the meantime, I think it'd be good if we could have a roll call of people that are here for the class? 13:08 * helen is here for the class :) 13:09 * daf too 13:09 too 13:09 * marga is here but won't be able to stay for the whole thing. :-\ 13:09 * helen even promises to not throw any more paper planes at vorlon ... 13:09 * vorlon grins 13:09 at least, not unless you deserve it... 13:09 marga: will you be here for the first hour? 13:09 * jvw moo! 13:10 I'll try to stay awake the whole time ;) 13:10 and helix 13:11 okay, 8 people admitted they were listening, general IRC rules say there are at least 8 more lurkers here... 13:11 ok, so we've got a good sized group; I guess anyone else is not so engaged yet that they'll respond in less than 2 minutes to a question, so we won't wait on them -- hopefully they'll follow along without needing to ask too many out-of-sequence questions. :) 13:11 vorlon: I don't really know, I might have to leave without much previous notice. 13:11 Maybe we should put up those url's again 13:12 I'm here, I'm here 13:12 s/again// 13:13 well, since there's been a request, let me go ahead and throw up my URL list off the bat: 13:13 http://people.debian.org/~vorlon/rc-bugsquashing-urls.txt 13:13 -!- vorlon changed the topic of #debian-women to: "Women in Debian" | Website: http://women.alioth.debian.org/ | Mailing list: http://lists.debian.org/debian-women/ | IRC meeting Jan 16 at 0500 UTC. | RC Bug Squashing Seminar 21:00-01:00 GMT | class is now in session http://people.debian.org/~vorlon/rc-bugsquashing-urls.txt 13:14 * akk is listening, just got back 13:14 -- that way people don't have to try to take notes as the URLs pop up during discussion :) 13:14 * helix will try to be a good pupil :) 13:14 ahh, thanks vorlon 13:15 anyway, so. Fixing RC bugs. We obviously have a bugsquashing party going on right now, which I've seen that several of you have already been participating in -- kudos. 13:15 this makes timing this on a Sunday somewhat suboptimal, since many of you won't get much use out of this now for /this/ BSP, but I would encourage everyone to not wait for BSPs before fixing more RC bugs! :) 13:16 always a next time... 13:17 I was also starting to get worried yesterday that people would eat up all the easy RC bugs and leave none for us... :) But true to form, we've gotten some new RC bugs since then, so I think I should be able to scrounge some up for everyone who wants one. :) 13:18 So, on page http://bugs.debian.org/release-critical/debian/main.html why are some bugs green? 13:18 bjb: They have a patch 13:18 But before we get into that, I suppose I should review the scope of this session. Today we're going to talk about how to pick RC bugs to work on, how to work on them, what to do when you've fixed them, when to give up on fixing them, and what to do when you give up. :) 13:18 sounds good ... 13:19 Hopefully I can fit that into the next 45 minutes, so that we can then spend a bit of time actually *working* on RC bugs together. 13:19 Anyway, to start off with -- picking RC bugs. 13:19 user2: rats :-) 13:20 Although some people seem to already be using the RC bug list on bugs.debian.org :), that's not the one we're going to be using here, because there's a nicer interface available: http://bts.turmzimmer.net/details.php?ignore=sid&ignnew=on&new=5 13:20 this page lists all RC bugs in Debian, that are older than 5 days, excluding bugs that are specific to sid (unstable). 13:21 vorlon: I think it might not be obvious why we're excluding new bugs 13:21 You'll notice from the top of the page that it gives additional filtering options -- including an option to ignore patched bugs. If you have that up in your browser, you might want to go ahead and click the box next to 'patch' and update, since we won't be working on bugs that already have patches. 13:21 * bjb wants to know why 13:22 I mean, why we aren't looking at bugs newer than 5 days 13:22 (which is point #1 -- there's little sense in working on bugs that supposedly already have patches available, unless your a DD) 13:22 daf: yes, thank you, good point. 13:22 bjb: to give maintainers a chance to fix it themselves 13:22 bjb: which is arguably better -- they know their own packages better 13:23 sounds reasonable 13:23 Right. The current Debian culture tries to encourage non-maintainer uploads, but we don't want to waste energy on them unnecessarily. If the bug is new, it's often better to let the maintainer get to it on his/her own. 13:23 So is 5 days the accepted convention, or is that a number out of the blue? 13:24 bjb: I think it's fair to say that there is no accepted convention about how long to give a maintainer to fix a bug 13:24 5 days happens to be when *I* start looking at them as a release manager; I usually let them age for a few more days before I'll consider it for removal, but at 5 days I'll start looking at whether there's some work that needs to be done on the package. 13:25 k 13:25 vorlon: can you explain the meanings of the other status checkboxes at the top? 13:25 so 5-7 days is the optimal time frame to get a patch into the BTS for the bug, otherwise the package might disappear from the list because it's been removed from testing. ) 13:25 helen: can I skip over that for the moment? 13:25 sure 13:25 helen: there's help available on the page itself 13:26 so right now, we've already excluded three groups of bugs that we want to avoid -- bugs that are too new, bugs that are only present in unstable, and bugs that already have patches. 13:26 vorlon: when do packages get removed from testing? 13:26 daf: I'd prefer to leave that question 'til the end as well, if you don't mind. 13:26 jvw: where? 13:27 helen: (hm, it's quite inadequate, let's let vorlon continue his talk, or /msg me) 13:27 ok :) 13:27 vorlon: sure 13:28 the remaining buttons on the page are a little muddled, so probably aren't going to help us here. We also want to skip over bugs that are claimed by someone else at the BSP -- but not necessarily bugs assigned to QA, so we can't use that button. 13:29 We also probably want to ignore bugs that have delayed uploads, but we *don't* necessarily want to ignore bugs on packages that are "hinted" (tagged for removal by the release team), so we don't use that button either. 13:29 there's enough color/text coding on the page, however, that we should be able to exclude those bugs visually without too much trouble. 13:30 how often do that page update itself? 13:30 jvw: do you know? 13:30 oh, there it is at the bottom of the page -- 15 minutes :) 13:30 vorlon: I'm currently documenting helen's question on bts.tz.net :) 13:30 * vorlon grins 13:31 vorlon: so I tell her to RTF page :) 13:31 the page updates every 15 minutes ttbomk 13:31 the other bugs that we're going to want to skip over on this page are: 13:31 bugs that are specific to hardware you don't have access to (but we may come back to these later) 13:32 and bugs on kernel-*, initrd-tools, glibc, and partman 13:32 console-tools has bugs on bts.tz.net and on packages.qa.d.o, but on haxx.se latest is already in testing ;-) 13:32 because you have to be a magician to fix them, right? 13:32 the first three of those (pseudo)packages that I'm excluding, are because you have to generally be a magician to work on those packages at all. :) 13:33 more importantly, the chance of a NMU without being an expert in them not breaking anything is neglectible... 13:33 to be more exact, they all have strong maintainer teams, so they're not really good NMU candidates -- the RC bugs there tend to require a high knowledge investment to understand how to fix them, and there's little sense in investing that much effort when there are already teams of people who *have* the knowledge to fix them. 13:34 Each of you can decide for yourself when you're ready to tackle bugs like those, but they're not good choices for beginners. 13:34 The last package, partman, isn't off-limits to newbies; I just happen to know that the particular bug that's there now is insurmountable for a lone patcher. 13:35 user1: er, those data are not in conflict. That just means that the latest version of the package is buggy. 13:36 vorlon: ahh, I see. the RC-bug was to late for stopping it's move to testing. 13:36 anyway, that's the list of bugs we want to avoid for the time being. You'll see that still leaves a pretty good number of candidate bugs -- 70 or so -- that I'd welcome you to look over for a few minutes. 13:37 vorlon: are we looking for something we think we might be able to fix? 13:37 helen: yes, though I'm not going to hold you to it at this point. :) 13:37 vorlon: or just looking for the sorts of things there are? 13:37 * helen gazes at the list... 13:37 woo, maybe my sparc will come in handy 13:37 anyway, since 70 bugs is still quite a few to sift through, your best rule for further winnowing down the list is to look for bugs on packages you *use*. 13:38 If you can't find any on packages you use, or you don't feel able to take on the ones that are there, please consider helping with other bugs on the page! They're still important for the release process, even if you don't directly need those packages to be fixed. 13:38 user1: yes, exactly. 13:38 so we are ignoring the yellow-highlighted ones? 13:39 What does it mean when a bug is "pending"? (Has a P in the square brackets at the left) 13:39 helen: yellow highlighting on that page only means that someone's commented the package on this page 13:39 bjb: that means that somebody says that the bug has been fixed, but that the fix hasn't been uploaded 13:40 vorlon: ok, most of the yellow comments seem to be reasons why the bug shouldn't be a worry now 13:40 it's not even a comment on the /bug/, but on the package; so some of the comments are stale from previous BSPs, and some are just informational -- they don't mean you should avoid the package. 13:40 oh, ok. 13:40 helen: yes, but many of the yellow messages, even the ones from this weekend, are pretty useless. :) 13:40 Why are some words like "optional" and "important" sometimes in red? 13:41 I think that's what sort of package it is? 13:41 bjb: there's a reference for bug tags at http://www.debian.org/Bugs/Developer#tags 13:41 bjb: "pending" means that someone has asserted that the bug will be fixed soon. On its own, this isn't all that telling either; everyone /intends/ to upload and fix their bugs... 13:41 the red means it's a security bug. 13:41 bjb: If the bug and it's line is red, it's a security related bug. 13:42 vorlon: presumably, one shouldn't use the pending tag unless they've actually managed to fix the bug, though 13:43 So if after looking through the bug list you still can't find one that you can tackle (and you don't have to have one right now, don't worry), please look at bugs in unstable as well (by switching ignore by distribution: sid to ignore by distribution: sarge). 13:43 No, I mean the keyword "optional" or "important" on the same line as the package name. Eg libgnutls10 13:43 bjb: yes, it's red for the same reason. 13:43 daf: shouldn't. But anyway, until it's in the archive, it doesn't completely count. 13:43 jvw: I hope you're taking notes about how to improve that page :) 13:43 daf: I log everything 13:43 obviously one shouldn't make it a priority to fix bugs the maintainer claims he's working on, but if they're still there... 13:43 vorlon: I guess it's roughly as useful as "patch", then 13:44 meanwhile cursing aba's dreadful coding style 13:44 daf: less useful; at least with "patch", the solution is there for any developer to see. 13:44 ok 13:45 vorlon: why have you made that (non) comment on 283896? 13:45 Please do note that packages not in sarge will never show up on the bts.turmzimmer.net list 13:45 vorlon: ibdbd-sqlite-perl 13:45 if you get to the point of needing to look at bugs specific to unstable, please limit yourself to bugs in packages you actually use; a well-intentioned NMU on a package that should actually be orphaned and/or removed from the archive can be worse than letting the package fester in unstable. 13:45 (right, jvw? :) 13:45 helen: UI bug on the page, it's the only way to delete a comment. :) 13:46 Correct, a package in a bad shape often also indicates that maybe nobody cares about the package 13:46 If that is the case, sarge is better off having the package removed, than the bug fixed in BSP 13:46 I was assuming I should start with packages I already used anyway. 13:46 ... and I'm afraid that's as much as I have in the way of recommendations for picking bugs out of the list. I'm going to hurry right along here, so I can fit the rest of this screed into the next 15 minutes. 13:46 Otherwise I have to learn how to run the program and understand what it does in order to test. 13:47 helen: which package? I'll remove it 13:47 helen: nvm 13:47 akk: yes, certainly it's best to start with packages you use, but please be willing to go beyond that point if necessary 13:47 vorlon: you can use 'no comment', than it'll be gone 13:47 If you are looking for bugs of packages you are using (have installed), you might be try to use the script "rc-alert" in the devscripts package. 13:48 jvw: hah, that's new. :) 13:48 vorlon: indeed, by popular request :) 13:49 so looking at the bugs that are left on the list, I have some comments on common classes of bugs you'll find there, and how to work with them. 13:49 does anyone know why #287193 (dia: FTBFS: Can't find python >= 1.5.2) was closed and then reopened and tagged "sarge". It seems simple... 13:49 helen: closed by an upload to unstable; upload hasn't reached testing yet, so it was reopened and tagged. 13:49 we'll talk about that in a little bit. 13:49 ok :) 13:49 So one of the largest classes of RC bugs is FTBFS (fails to build from source) bugs. 13:50 These usually get detected in sid (since failing to build usually blocks the package from reaching testing), so they wouldn't show up on this list 13:50 but as the release progresses, we've gotten automated rebuilding tests of the testing suite, and also some build failures are caused by changes in other packages, so lately there are plenty of them on the list (and there are always at least a few) 13:51 these are pretty easy bugs to get started on -- you know there's a build failure. This doesn't mean they're always easy to fix :) 13:51 If the failure is on an autobuilder, though, you have http://buildd.debian.org/ to use for finding full build logs (hint: start at the bottom of the log file ;), even if it's for an architecture you don't have access to. 13:52 If it wasn't on an autobuilder, the bug report should include info on how to reproduce it; and once you can reproduce it, you can start debugging it. 13:52 yes, managing to reproduce an FTBFS can be a challenge 13:52 yes, but your best tool is usually refined trial and error :) 13:52 :) 13:53 So, many packages uploaded to the archive may have built on the developer's machine but nowhere else. This is usually caused by missing build dependencies -- this is one of the easiest kinds of FTBFS to fix. 13:53 Most missing build-dependencies can be figured out with a healthy dose of ap-cache search... and some trial and error. 13:53 Other packages will have arch-specific build errors. Even if you don't have hardware of that architecture, the build logs may tell you enough to debug the problem. Don't be afraid to try! 13:54 You may not understand all the error messages, but looking at the source (many of these errors will give you a line number to work with) and asking your friendly neighborhood web search engine may give you enough to try a few guesses. 13:54 Who knows, you may just learn a programming language in the process. ;) 13:54 heh 13:55 Still other packgaes might have once built, but no longer build anywhere. There's no one-size-fits-all recipe for fixing these, but these also often require updated build dependencies. 13:55 another class of bugs would be "policy violating weirdness". A lot of these are install/uninstall failures, but there can be other policy bugs in a package that get marked as "serious" bugs. 13:56 My biggest advice here: if you can reproduce it, you can probably fix it. 13:56 where policy is official Debian policy from http://www.debian.org/doc/debian-policy/ ? 13:56 especially if you can also fail to reproduce it ;) 13:56 Figure out what the bug submitter is reporting, and try to reproduce the problem. (chroots can be useful for this if you don't want to mess your main system.) 13:57 helen: yes, thank you. Added to the URL list 13:57 Once you've reproduced it, make sure you understand what policy says *should* happen. 13:58 Then poke around in the debian/directory to find the culprit... 13:58 change, rebuild, test. 13:58 submit patch. 13:58 :) 13:58 vorlon: how about explaining how to submit a patch? 13:58 helen: I'd like to cover a few more bug groups first, if I could 13:58 (and quickly, of course) 13:59 sure, don't mean to interrupt 13:59 the next group of bugs is security bugs 13:59 don't be afraid of these bugs just because they say "security". 13:59 is someone taking notes so that this can be turned into a debconf talk? ;-) 13:59 Even if you don't know the language used to implement the package, it may be possible to help with security bugs by tracking down information 13:59 mdz: logging.. :) 13:59 indeed, most of the work in security is information gathering 14:00 Many security bugs start out with little more information than a CVE ID (CAN-*) when they reach the BTS -- with no real explanation of what, or where, the bug is. 14:00 The silo package has a red "important" even though none of the bugs in the list is a security bug. 14:00 Some web research can help track this information down for the maintainer: sometimes in the form of text explanations of the security bug, sometimes in the form of actual patches published by other vendors (or by upstream). 14:00 and mdz, feel free to interject here. :) 14:01 I wrote a section in the developer's reference about how to help with security bugs 14:01 http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security 14:01 The truly audacious may be willing to research such security bugs in upstream's revision control systems as well (works best if you understand the programming language well enough to recognize a possible security fix when you see one). 14:01 (I have documented all the ignore filters of bts.turmzimmer.net, for as far as that was doable...) 14:01 last group of bugs I have here are testing-only bugs. 14:01 bjb: I suspect it's because it has a security bug which is being filtered out by your settings 14:01 jvw: :) 14:02 Bugs that are tagged "testing" (T) might not seem like good candidates to work on, but a bug that's been tagged testing means that the package in unstable is not broken -- but that either that package version hasn't reached testing, or some *other* package needed to fix the bug hasn't reached testing. 14:02 bjb: no, packages that are frozen are now red too... 14:02 helen, here's where we get to bugs that have been closed, then reopened with a tag. 14:03 Sometimes the only thing neded to fix these is time, but sometimes there are other problems keeping the fixed package from hitting testing -- finding these problems, an dpointing them out to the maintainer (and submitting patches, always the patches!) can be a help. 14:03 I'll say that today, handling these bugs is pretty much exclusively the problem of the release team. It'd be nice if that changed. :) 14:04 *s* 14:04 To find out why a package isn't in testing yet, find the name of the source package (apt-cache show | grep ^Source -- if it doesn't return anything, the source package name matches the binary package name). 14:04 Then use the grep-excuses tool from the devscripts package, to find out what britney (the testing update script) says about why it's being kept out. 14:05 oh, I should take a step back here and say that for looking at testing bugs, you probably don't want to exclude 'patched' bugs from your list, since most of them will have patches. :) 14:05 anyway, let's take a look at the grep-excuses output of a live bug. 14:06 first testing bug (in gray) I see on the list is 'asterisk' 14:06 I think you can also see why something isn't in testing through here: http://packages.qa.debian.org/common/index.html can't you? 14:06 helen: not that I see. 14:07 go to a package page and click on "check why" it's not in testing yet? 14:07 oh, yes, now I see. :) 14:07 I though that was the same stuff? 14:07 http://bjorn.haxx.se/debian/testing.pl is also a great site to use for this 14:07 well, if you prefer the webpages you can; grep-excuses is a lot quicker, IMHO. :) 14:07 helen: yes, you can, this is indeed the same stuff, but the site gravity quotes is often more uptodate and informative 14:07 but anyway, grabbing asterisk... 14:08 gravity: yeah, that's what �http://packages.qa.debian.org links to, I think. 14:08 ~$ apt-cache show asterisk | grep ^Source 14:08 ~$ 14:08 - so the source package name matches; so we do grep-excuses asterisk... 14:08 asterisk (1:1.0.2-2 to 1:1.0.2-3.1) 14:08 Maintainer: Debian VoIP Team 14:08 Too young, only 0 of 2 days old 14:08 asterisk (source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc) is buggy! (1 > 0) 14:08 Not considered 14:08 the first two lines are obviously just informational. 14:09 the third line, "too young", seems like nothing that a little time won't fix. 14:09 * jvw . o O ( the webpage conveniently links to the BTS entry for that package... ) 14:09 the fourth line, however, reminds us that asterisk has another RC bug... and that this is a problem for getting the package fixed in testing. 14:09 jvw: true. :) 14:10 * bjb apt-get installs devscripts 14:10 so since this package has still another RC bug, we need to figure out how to get *it* fixed before the other one will be fixed for testing users. 14:10 other things you'll see here are missing binaries on some architectures. 14:11 for an example of this, see libqt-perl 14:11 hmm. or not. 14:12 It just says "too young, 0 of 2" 14:12 unfortunately, when the package is only 0 days old, the testing information doesn't *tell* you binaries are missing.:) 14:12 but we can still check for these by going to http://people.debian.org/~igloo/status.php 14:12 grep-excuses lilypond 14:13 aha 14:13 if we plug in libqt-perl in the 'packages' field on that page and search, we see that libqt-perl failed on mips and mipsel, with handy links to the logs. 14:13 so, linking this problem to the unfixed-in-testing bug can be a help to the maintainer, even if it means you have to file a new release-critical bug report in the process. 14:14 (which, for the record, I'll be doing tonight ;) 14:14 And last, sometimes a bug-fixing package gets held out by issues in other packages that it depends on. 14:14 jvw: thanks 14:15 yes, 'grep-excuses lilypond' shows what the output looks like on a package, more than 1 day old, that's missing builds on some architectures. 14:15 apt-cache show asterisk | grep ^Source 14:15 more like nearly all architectures... 14:15 vorlon: you're saying most packages will be built on all architectures within a day? 14:15 doesn't show anything for me 14:15 Technically, *missing* is not the criterion; the criterion is actually "out-of-date", which means, "this package previously built for this architecture and doesn't build there now". 14:16 daf: sometimes there are buildd delays, can be up to weeks 14:16 daf: I'm saying that until the package is one day old, the testing scripts don't bother telling you about missing builds, because nothing goes into testing on its own at 0 days. 14:16 it's a shortcut in the testing scripts to save processor time. 14:17 hmm, ok 14:17 any questions/concerns up to this point about what I had to say about the groups of common RC bugs? 14:17 if not, running on to the question of patching 14:17 * gravity tries to catch up on what he's missed 14:17 no questions from here 14:18 Once you think you've squashed the bug -- which usually means you've reproduced the bug in a controlled environment, made a change to the package, and confirmed that the bug went away -- you're ready to submit a patch to the BTS 14:19 for the actual creating of patches, please refer to marga's excellent tutorial in the wiki, http://women.alioth.debian.org/wiki/index.php/English/AdvancedBuildingTips 14:20 Once you have your patch, just send it to the bug report by sending a mail to @bugs.debian.org 14:20 (attachments preferred over in-line text, please) 14:21 you should also send a mail to control@bugs.debian.org with the text "tags ##### +patch" in the body, so that the bug shows up as a patched bug 14:21 and I'm going to stop this marathon here and field any questions, since we're well over time. 14:21 If, while working on the package, looking at packages.qa.debian.org/, and looking at the bugs and the general responses from the maintainer, you suspect that the maintainer might be missing in action (MIA), you could mail mia@qa.debian.org about it 14:22 Why do I get no output on apt-cache show asterisk | grep ^Source 14:22 ? 14:22 mail to that address remains confidential, by the way, in case you're not sure and don't want to offend the maintainer 14:22 How long should one wait after submitting a patch before suspecting mia? For either RC or non-RC bugs. 14:22 user2: that's expected when the binary package name matches the source package name. 14:22 akk: if the maintainer has shown no activity at all in ~3 months, you can mail 14:23 akk: that doesn't need to be just in reaction to _your_ bugs, but you can read logs of other bugs, too, and on packages.qa.debian.org, see about past uploads 14:23 a more consistent command might be 'apt-cache showsrc |grep ^Package' 14:23 seems I have overread something as there was too much background noise 14:23 or go to bugs.debian.org/, and follow the link about 'source package' on top 14:24 user2: yes, there is indeed supposed to be no output, vorlon's way of finding out source package is a bit tricky and complicated 14:24 akk: for better or for worse, if the package is in testing, an RC bug that's tagged patch won't stay long enough to give much of an idea of whether the maintainer is MIA. A better indicator is how long the bug was open without comment /before/ you submitted a patch. 14:25 akk: or look at bugs asking for new versions from upstream... 14:25 if they are open long time without reaction, that's a good hint too 14:25 jvw: please feel free to suggest a better interface for finding source package names; that's the one I happen to use because it's consistently quick to type. :) 14:26 so have I bored people out of the channel, or is everything just so clear that there are no more questions? 14:27 oh, I forgot to cover what to do when you /don't/ succeed in fixing the bug. 14:27 vorlon: I have some mozilla shortcuts into bts, pts, packages.d.o and ddpo, I use those mostly... 14:27 some bugs are just harder than others, and you might not be able to fix it on your own. 14:27 that's ok -- if you want to stop, or you can't think of anything else to change that might help, you can still send valuable info to the BTS 14:28 for instance, if it took you a while to figure out how to reproduce it because the info in the original bug wasn't clear, sending more info to the bug report about how to reproduce the bug is helpful 14:29 For example, while working on a bug, you either could not, or could reproduce the bug -> valueable information 14:29 still looking through the list of bugs to try to find one, and trying out all those commands we've learned 14:29 if you reproduced it, and tried things that you thought *should* have fixed the bug but didn't, that can also be helpful. 14:30 vorlon: not bored, but it's still hard to spot bugs to work on 14:30 helen: ok, if there are no more questions, I'm happy to start doling bugs out to people :) 14:30 but I am wondering whether we should take that discussion over to #debian-bugs, once the tutorial phase is over? 14:30 This must be the part vorlon has been waiting all weekend for :-) 14:30 * vorlon nodnodnods to gravity ;) 14:30 so this channel can be freed for people to talk about other stuff too 14:31 I'm going to take another stab at webchecker, unless someone who really likes and knows python wants to try it 14:31 I talked to the mailman & msttcorefonts maintainer, and he just arrived back from holidays, and will look into his packages tomorrow 14:32 ok, I probably need another roll call of people who would like to try working an RC bug with help, and need a bug #. 14:32 gravity: webchecker? 14:32 for mailman, testing those patches in the BTS is appreciated by him 14:32 vorlon: in the other channel? 14:32 yes, let's move that to #debian-bugs now. 14:33 vorlon: :) 14:33 daf: Sorry, webcheck. It's owned by QA, and it seems like its major issue is with a python update 14:33 so if you're interested in having an RC bug assigned that you can try to work on, please join #debian-bugs (if you're not already there), and grab my attention there or in /msg