=== asac_ is now known as asac [15:58] #startmeeting [15:58] Meeting started at 09:58. The chair is robbiew. [15:58] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [15:58] hi liw [15:58] hi TheMuso [15:58] Hey folks. [15:59] afternoon [15:59] * mvo waves [16:00] yo [16:00] hi-ya [16:02] hello [16:02] Keybuk: are you here? [16:02] I'm always here [16:02] hhe [16:03] cool [16:03] I have always been here [16:03] not much as a formal agenda goes [16:03] [16:03] http://launchpad.net/bugs/290400 [16:03] LINK received: http://launchpad.net/bugs/290400 [16:03] Launchpad bug 290400 in ubuntu-meta "DVD livefs always removes java packages" [High,Triaged] [16:04] this is currently unassigned...and an apparent bother for Dell :) [16:04] any takers? [16:04] is this jaunty? [16:04] so the assignment to ubuntu-meta is a bit ... confused [16:04] heh [16:05] the problem is not really that metapackages are inadequate, although I suppose that would be one possible way to fix it [16:05] Java is pulled in because of (indirect) dependencies from language-support-* [16:05] one thing we could do would be a hack in ubiquity to say "if Java's on the livefs, we might as well keep it" [16:05] although Mario's proposal would perhaps be a more elegant way to do that [16:06] oh, well, I said that the ubuntu-meta bit was confused and now notice that I put it there myself ;-) [16:06] * cjwatson blushes [16:06] heh [16:07] java is overrated anyway [16:07] completely :P [16:07] why don't I take it; I already gave Evan one of the other OEM priority bugs today [16:07] cjwatson: thanks [16:07] oh? [16:08] heh [16:08] I missed this assignment entirely [16:08] bug 335557 [16:08] Launchpad bug 335557 in oem-config "new TZ map needs to be ported to oem-config" [High,Triaged] https://launchpad.net/bugs/335557 [16:08] * evand curses gmail for not having anything approaching decent mail filtering [16:08] thanks [16:08] noted; will do [16:08] * liw says inboxzero.com and hides [16:08] figured it was probably more sensible for you to do that than for me to try to guess [16:09] sure thing [16:10] I've been told by QA that I should review this list: [16:10] http://qa.ubuntu.com/reports/team-assigned/ubuntu-foundations-assigned-bug-tasks.html [16:10] LINK received: http://qa.ubuntu.com/reports/team-assigned/ubuntu-foundations-assigned-bug-tasks.html [16:10] and mark bugs that we should *not* have [16:10] If I did inbox zero on the ubiquity bug mail I'd surely go mad and start drawing on the walls and storing bottles of urine. [16:10] so there are some things on there, at least for me, that are there due to personal interest and that basically have little to do with my paid work [16:10] "If the team decides that it cannot realistically take responsibility for a given bug it should be assigned to Nobody (or a suitable community team) and the 'ct-rev' tag should be added " [16:10] how do you want those annotated? [16:11] for example, bug 329375 [16:11] Launchpad bug 329375 in groff "groff version is too old" [Wishlist,Triaged] https://launchpad.net/bugs/329375 [16:11] cjwatson: hmm...good question [16:11] I think they can stay [16:11] muah ... bittorrent still in main? [16:11] it's marked Wishlist..so I won't really pay much attention to it, to be brutally honest [16:11] ct-rev? [16:11] robbiew: right, just an example [16:12] robbiew: let's say bug 161047 then [16:12] Launchpad bug 161047 in openssh "ssh server forces a command when it should not" [High,In progress] https://launchpad.net/bugs/161047 [16:12] cjwatson: ah [16:13] robbiew: I haven't even seen half of these bugs that are apparently assigned to me [16:13] TBH, I think most things that are assigned to me personally are there because I set them that way [16:13] i.e. don't want to forget about them, and intend to do something about them eventually, but that doesn't necessarily indicate anything about their urgency [16:13] cjwatson: I'm still okay with it [16:14] I use this to see approximate bug workload...nothing else [16:14] I'd like to jump in and suggest that "assignment" to a community team is not generally appropriate. [16:14] people do occasionally randomly assign bugs to developers who look plausible [16:14] I usually tell them off and unassign when they do it to me :-) [16:14] ScottK: it's a way to let our QA team notify me of a bug for the team...when they aren't sure who on it should get it [16:15] only rarely done...at least for our team :) [16:15] robbiew: I was referring to the "or reassign it to a community team" bit. [16:15] I am happy to say that all of the bugs on there are basically appropriate for me, even though they are not necessarily either urgent or a general team responsibility [16:15] (er, the ones assigned to me that is) [16:16] ScottK: oh [16:16] cjwatson: right...I suspected that most are "appropriate"...and btw, we KILL the other teams in bug assignment [16:16] heh [16:17] that is going to take some time to go through the complete list [16:17] not sure if that's good or bad [16:17] mvo: right, and I think update-manager is unfairly "blamed" for bugs in other applications [16:17] mvo: did you see any new python related upgrade errors this week? If not, I'd like to announce that we finish the upgrade, and that it should be safe to upgrade again [16:17] we've only started using the ubuntu-foundations team as a temporary holding area for bugs very recently [16:17] mvo: so you may have some work to do :) [16:17] robbiew: indeed [16:17] in contrast to e.g. ubuntu-desktop and ubuntu-kernel-team who've been doing so for a long time [16:17] doko: There's still lots of Universe/Multiverse to do. [16:17] ScottK: yes, I know [16:18] doko: I have not done a lot of triage this week, sorry [16:18] cjwatson: true [16:18] * liw rejoices in the fact that update-manager will now be blamed for computer-janitor's problems :) [16:18] liw: ... but you need to subscribe to update-manager's bugs ;-) [16:18] ok, so that's all I have besides the usual SPONSOR, SPONSOR, SPONSER push [16:18] liw: right, you are now *maintainer* of it too :P [16:19] liw: +1 to cjwatson [16:19] mvo, oops :) [16:19] liw: congratulations! heh [16:19] james_w: ready? [16:19] yeah [16:19] * robbiew yields the floor :) [16:20] I've got a question related to the Launchpad API, but I think it's something that someone might have come across elsewhere [16:20] oh wait...one more reminder: All hands proposals in by this Friday! [16:20] ok...sorry james_w [16:20] np [16:20] I want to know which packages have been published since the last time I checked [16:20] launchpad allows you to specify a date in the query which to show since [16:21] but I don't think there's a way to get its idea of the time [16:21] oh, you mean to make sure your time is synced with LP's? [16:21] so how should I design this such that things aren't missed due to clock skew or changing clocks? [16:21] yeah [16:21] here's a stupid workaround [16:21] assume that your local clock is accurate to within a day [16:22] ask for all packages since (last time you checked - one day) [16:22] keep a record of the answers so that you can eliminate duplicates [16:22] for some value of "a day" [16:22] if you are doing HTTP then the server tells you the time, which you store and then send back in the "If-modified-since" header. This is based on http, but I don't think it's exposed/usable [16:22] yeah that's what I was thinking [16:23] what's the API call in question here? [16:23] I don't even need to remove duplicates, as there is no harm in doing extra work [16:23] just trying to balance efficiency with safety [16:23] I could do a full re-scan once a day or so to ensure nothing is missed as well [16:24] just looking... [16:24] the problem about relying on the server's time is that presumably in theory LP's different appservers might be skewed [16:24] in practice I imagine they're NTPed [16:24] getPublishedSources I think [16:24] so for correctness you probably have to build in a margin anyway [16:25] I looked at getPublishedSources but don't see a "date since" field [16:25] then there are a bunch of date fields on the result [16:25] oh, right, you just have to ask for them all then filter? [16:25] it looks like it [16:25] well, in *that* case I think you can safely assume that time on the production database is monotonically increasing [16:25] I want to avoid the expensive calls to find all publications in all series for that package [16:26] so just remember the latest time it gave you last time, and then look for the next one after that? [16:26] that seems to be sensible [16:26] thanks, I'll give it a go [16:26] I'm hoping that the production database keeps its times in UTC [16:26] me too :-) [16:26] if not I think we would probably notice problems ;-) [16:27] james_w: cool...is that all? [16:27] that's all I had, thanks robbiew [16:27] and thanks cjwatson [16:28] ok...remembered one more item. We're starting 9.10 requirements meetings this week and next...so you may get pinged for some info...just FYI [16:28] AOB?...Good News?? [16:29] going once... [16:29] we should get some compiz speedups [16:29] :D [16:30] Keybuk: have you had a chance to test the changes on the mini9? [16:30] robbiew: no, because of other breakages [16:30] I think the race condition nightmares that bit us from alpha 5 should be basically dead now [16:30] cjwatson: that's REALLY nice to hear :) [16:30] Keybuk: grrreat :( [16:30] I asked asac to test the change, but his mini9 is running jaunty for other reasons, so I could only test it on my system [16:30] mostly due to Keybuk, but I added a few bits of synchronisation to partman-lvm too [16:30] where it brings down stattup from 3s to 2s [16:31] (on the second run that is) [16:31] mvo: s/jaunty/hardy/ [16:31] mvo: let me check for a jaunty image now [16:33] ok...looks like this meeting is running out of steam :P [16:33] #endmeeting [16:33] Meeting finished at 10:33. [16:33] UI freeze is tomorrow, right? [16:33] land your UI changes now :-) [16:33] TheMuso: fyi, got your proposal and am digesting it now [16:33] cjwatson: ah, yes [16:33] cjwatson, what, tomorrow? [16:33] gah [16:33] robbiew: ok [16:33] why isn't it in my calendar [16:33] * mvo wonders why http://launchpad.net/bugs/291262 is assigned to him [16:33] Launchpad bug 291262 in python-central "MASTER - package failed to install/upgrade: pycentral pkginstall: not overwriting local files" [High,Triaged] [16:34] mvo: you are the python upgrade master ;) [16:34] * mvo unassigns himself [16:35] thanks all! [16:35] thanks [16:35] mvo: we could set overwrite-local to default, now that we know that newly local installs go into /usr/local for 2.6 [16:36] doko: I would welcome that change [16:36] doko: should I assign to you? [16:36] thanks! [16:37] doko: having the environment (as in my patch) would be nice as well, then update-manager cna force it for upgrades, but its not essential [16:37] mvo: you *can* welcome it. it's there. or do you mean the change of the property? do you want a environment var for u-m? [16:39] doko: what I wanted to say was that I would welcome making force-override default or to have a way for update-manager to make it default (that is simpler than editing a conffile) [16:40] mvo: ahh, ok [16:40] but with the new layout it should be much less of a issue anyway [16:57] heno: I won't be able to attend the community meeting, sorry. Please check my email with my updates. can you say udt point on my behalf, please? (email has the details) [16:57] thanks [16:58] ara: got it thanks [16:58] no worries [16:58] hello [16:59] * heno waves [16:59] * bdmurray waves [16:59] * cgregan waves [16:59] hello everybody [16:59] hey [17:00] * charlie-tca waves [17:01] bdmurray, ogasawara, cr3: ping [17:01] * ogasawara waves [17:01] * bdmurray waves again [17:02] ah, sorry bdmurray :) [17:02] ok, we can start! [17:02] #startmeeting [17:02] Meeting started at 11:02. The chair is heno. [17:02] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:03] lots of good topics again today: https://wiki.ubuntu.com/QATeam/Meetings [17:03] [TOPIC] UbuntuBugDay highlights. [17:03] New Topic: UbuntuBugDay highlights. [17:04] howdy [17:04] welcome eeejay [17:05] I wasn't around last hug day but it seems that a good progress was mode https://wiki.ubuntu.com/UbuntuBugDay/20090226 [17:05] everyone: eejay is working on desktop test automation, specifically the dx stuff [17:05] currently the notifications [17:05] hey eeejay :-) [17:05] hello [17:06] * fader waves. [17:06] hi folks :) [17:06] He's also the upstream maintainer of Accerciser :) [17:08] do we have a summary of last weeks bug day? https://wiki.ubuntu.com/UbuntuBugDay/20090226 [17:08] eeejay, heno: I have a new hire jcollado who is doing some automation work as well.....we should maybe get the entire group in a call next week [17:09] or should we just introduce tomorrow's https://wiki.ubuntu.com/UbuntuBugDay/20090305 ? [17:09] I was expecting to Mrkanister to give us some stats about the past one but he is not online atm [17:09] yeah, tomorrow hug day is based on flashplugin-nonfree [17:10] cgregan: or we can just speak face to face at the sprint :) eeejay will be there as well [17:10] people already started to do some work on it, so feel free to start grabbing and squashing bugs before is too late [17:10] heno: sounds good [17:10] yup, /me will be there [17:11] for those who don't know - we have a desktop automation sprint here in Oxford next week [17:11] mostly Canonical folks, but a few external invites [17:11] we'll follow up with sessions at UDS and Guadec/Akademy as well [17:12] thanks pedro [17:12] that brings us to: [17:12] [TOPIC] April Ubuntu Bug Days, it was proposed to freeze them since the release is coming out that month [17:12] New Topic: April Ubuntu Bug Days, it was proposed to freeze them since the release is coming out that month [17:13] pedro: ^? [17:13] heno: might it not be better to take the time to work on hardy bugs ready for hardy.3 [17:13] Right, I've been talking with Mrkanister about that, and we think that i'd be good idea to put the hug days on hold for that month [17:13] and concentrate our efforts on the release rather, doing testing, trying to discover new critical bugs, etc [17:13] Why's that? [17:13] (btw, let's start adding names to agenda items so we know easily who posted them) [17:13] would we convert the hug days to testing days? [17:14] we could do that, yes [17:14] Maybe if we changed the focus of bug days from less per package but rather to no package or new w/in the past week or bugs with patches? [17:15] bdmurray: right, we want to schedule a bugs with patches hug day just after the release to grab the attention of the developers to them and hopefully include those patches to next release [17:15] if they apply to that of course [17:16] davmor2: yes we should come up with a few tasks like that to recommend instead but people should work on those independently so we don't take up too much of people's bandwidth around release [17:16] couldn't we try and get some of them in for Jaunty? [17:17] before RC at least that could work [17:17] if we run a bug day the Thursday before RC [17:18] I don't think we should have one the week of RC or Final [17:18] that'd be Thursday 09 April [17:18] heno: that makes sense to me [17:18] The week after we could have a 'catch new bugs for SRUs and Karmic' day [17:19] April 30th [17:19] sounds fine to me [17:20] I'll add those to the Planning page then [17:20] so skipping a couple sounds good but not the whole month? [17:20] bdmurray: yup [17:20] We'll have several smoke testing days on Mondays anyway [17:20] (with the first one next Monday) [17:21] seems like we have consensus there! [17:21] yup thanks ;-) [17:21] [TOPIC] Next Testing day topic & highlights from last UTD [17:21] New Topic: Next Testing day topic & highlights from last UTD [17:21] Here we are referring to the one week after next [17:22] next week is a smoke day :) [17:22] Yay [17:22] A notifications testing day has been suggested, but you are travelling then eeejay? [17:23] http://testcases.qa.ubuntu.com/Plans/SmokeTesting plan is here if anyone wants to add any thing [17:23] LINK received: http://testcases.qa.ubuntu.com/Plans/SmokeTesting plan is here if anyone wants to add any thing [17:24] schwuk: let's pass around some CDs at the sprint on Monday too :) [17:24] heno, on th 16th? [17:25] right, thought you had mentioned that [17:25] heno, i had, but I will be here for most daytime European hours [17:26] I should be able to be online through 1700 UTC [17:26] ok great, let's pencil that in then [17:27] ara had to step out but send me an update from the last testing day: [17:27] * totem & rhythmbox [17:27] - A couple of bugs were found for totem & two more in rhythmbox. [17:27] - I proposed a fix for the totem one, waiting in the sponsorship queue. [17:27] - davmor2 was again very responsive [17:27] - Less new people than the previous one. jcastro: how do you think we should encourage more people to participate? [17:27] - A calendar for the next UTD is now at https://wiki.ubuntu.com/Testing/UbuntuTestingDay/Calendar [17:29] i hope ara (or somebody else) could help me prep for the next bug day, not sure how good the cases we have are so far [17:29] expecting to do that at the sprint [17:29] eeejay: we should make good progress at the sprint, yes [17:30] [TOPIC] lp-upstreaming tool - Jorge Castro sent an email asking for testing. [17:30] New Topic: lp-upstreaming tool - Jorge Castro sent an email asking for testing. [17:30] eeejay: I think there are some for notifications but are out of date I can update that though and you can complete it [17:30] davmor2: I started work on them here: http://testcases.qa.ubuntu.com/Applications/Notification [17:31] jcastro: here? [17:31] So I've tested it a bit ... [17:31] heno: he is sprinting atm IIRC [17:32] ok [17:32] * Bug 18505 has an upstream task and link already [17:32] Launchpad bug 18505 in gimp "Can cause corruption if cancel while a save is in progress" [Unknown,Confirmed] https://launchpad.net/bugs/18505 [17:32] so that seems to be a false positive [17:32] * I'd like to be able to see the whole bug - perphas an 'Open in FF' option? [17:33] (in addition to y/n/q) [17:33] I'll file bugs about these [17:34] that makes the workflow a bit slow for me, i don't really like to be asked each time, instead i'd like to give to the tool a set of bugs from the command line [17:34] but it seem jcastro was faster than me on that and he filled bug 329119 [17:34] Launchpad bug 329119 in lp-upstream-tools "Should support arbritary bugs on the command line" [High,Triaged] https://launchpad.net/bugs/329119 [17:34] which is exactly what'd like to have [17:35] eeejay: kwin is not a targetted environment for notify-osd. [17:35] pedro_: how do you know they should be upstreamed, had you already looked at the bug (in your workflow)? [17:35] so please if you find that the tool isn't doing what's expecting to do or you want to request a feature, please fill a bug under the lp-upstream-tools product -> https://bugs.launchpad.net/lp-upstream-tools/ [17:37] heno: exactly, for bugs I've already looked during the day [17:37] ScottK, not for this cycle. right [17:37] eeejay: There is no agreement about it ever being a target. [17:38] I'd suggest remove it and leave that to the next UDS to figure out. [17:39] Most fundamentally for me though: We don't currently track which bugs are not actually candidates for upstreaming. So when I looked at the gimp bugs today the ones that did not have a task were not really suitable for that. The next person who runs the script will have an even worse hit rate [17:39] we need a flag for this-is-likely-not-an-upstream-issue and filter on that [17:40] maybe opening an upstream task and marking it invalid? [17:40] We've spoken about using a tag while waiting for an LP flag [17:40] bdmurray: that's an option === erhesrhsrtb54vyh is now known as Elbrus [17:42] jcastro, pedro_: can you look at the possibilities for this with gmb? [17:42] ok, next: [17:42] heno: yeap, I'll raise it with them [17:42] [TOPIC] debconf questions that use a check box? [17:42] New Topic: debconf questions that use a check box? [17:43] pedro_: the upstream report should reflect that state too [17:43] heno: indeed [17:43] I was doing an upgrade this morning and noticed that some debconf prompts are phrased as questions but have a checkbox which seems odd to me. Has anyone else noticed this? [17:44] bdmurray: Not consciously but now that you mention it, yes [17:46] bdmurray: does this require further discussion? seems like a bug should be filed against the offending packages [17:46] I was curious if other people thought it was a bug too. Also how can we find these without doing tons of upgrade tests. [17:46] bdmurray: I don't do that much in the way of updating I normally install fresh so may be missing them due to that [17:47] ideally we should minimise prompts at all [17:48] bdmurray: is there a way to query for packages that have debconf questions? [17:48] sbeattie: That's what I'd like to know! ;-) [17:48] bdmurray: don't you tend to get these on system wide changes to things like mysql and things like that? [17:48] Okay, I'll do more research into it I guess. [17:49] ok, thanks [17:49] [TOPIC] Improving the information flow between bugsquad and developers [17:49] New Topic: Improving the information flow between bugsquad and developers [17:49] has everyone read http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/03/02#2009-02-27-bug-triage-rants ? [17:50] aye [17:50] not much of a rant, cjwatson Too balanced ;) [17:51] So, stepping back good bug triage can actually be hard, esp of certain packages like the installer and kernel [17:52] we shouldn't fault people too much for making some mistakes but we should look at better procedure for catching and correcting earlier [17:52] I think one think here that might help is if an explanation of different modes is added to the talks for GBJ there were a lot of new triagers there who were just told to not touch a bug if it is assigned to someone but not much else [17:52] Having developers participate in bug jams and bug days helps [17:53] because they can provide feedback real time [17:53] I would also suggest that people contact the devs of teams related to a package they intend to triage a large number of bugs for, with a heads-up [17:54] To what end? [17:55] bdmurray: debconf> sounds like standard debconf behaviour on booleans [17:55] might be a wording problem in the questions involved of course [17:55] bdmurray: I'd send Colin a message saying I'm planning a run though the Ubiquity bugs next week - please have a look as the first hit your inbox on Monday and let me know if I'm on track [17:55] cjwatson: wording problem is a good way to describe what I'd seen. How could we go about finding those? [17:55] bug triage> the biggest problems I have had are when people suddenly triage a couple of hundred of my bugs without talking to me first [17:56] cjwatson: what would you tell them? [17:56] bdmurray: look at /var/lib/dpkg/info/*.templates, looking for Type: boolean [17:56] bdmurray: the worst problems are when somebody decides that all of my bugs are too old and therefore must be stale [17:57] it generally wastes a vast amount of my time to disentangle everything and pacify bug submitters who are fed up of being asked to confirm the continued existence of their bug for the nth time [17:57] but I would guide them to the areas that I think actually need work [17:57] and generally attempt to establish a relationship with them where they could quickly fire me questions on IRC or whatever [17:58] I see your point and agree that's problematic it just seems that there should be a better way to document what you'd like to see rather than having a conversation every time someone wants to look at bugs in package X. [17:58] well, the comments I made are things that I think should be general practice [17:58] I am generally concerned that there is a mistaken belief that bugs go off with age [17:58] also, those who are triaging confirmed bugs, just because they are more than a few months old [17:59] I am generally concerned that people think that wishlist bugs are bad [17:59] cjwatson: "my bugs" == bugs assigned to you, bugs in packages you subscribe to, and/or some other way of identifying those? [17:59] I agree with your blog post, I was more concerned with e-mail developer before triaging bugs bit. [17:59] I am generally concerned that people think it's OK to close bugs that aren't actually gratuitously incomplete without checking with the appropriate developer [17:59] etc. [17:59] bdmurray: I think that's a good way to avoid problems, but not necessarily the only way [18:00] is there a link that is a devel directory? That could be a good thing to add to bug days etc. Then if a devels name appears anywhere in the bug leave it. [18:00] bdmurray: not for a single bug but before doing a large sweep of hundreds of bugs [18:00] sbeattie: one might spend some time reading about the package one's working on and trying to figure out the history [18:00] sbeattie: that would be a useful thing for triagers to know how to do anyway [18:00] sbeattie: since the history is usually very important information [18:00] davmor2: I suggested the lp_karma_suffix greasemonkey script [18:01] Should we add a section about communication to https://wiki.ubuntu.com/Bugs/HowToTriage/ ? [18:01] There's also DeveloperResponsibilites [18:01] I didn't want to give the impression of "get off my lawn", BTW [18:01] but I do think that sometimes people forget that the point of bug triage is to help developers work more efficiently, so that's actually an important thing to check up on every now and then :) [18:02] I do have a major concern that people are acting on well-written bugs that they just don't understand [18:02] I'm not faulting them for not understanding everything, obviously! [18:03] but if something shows up that I don't understand, my instinct personally would be to stay clear rather than to give a stock request for more information or to close it pointing to brainstorm [18:03] I have encountered quite a number of people who've said that they don't bother reporting bugs to Ubuntu because they would rather talk to somebody knowledgeable - and I think that's a really bad thing [18:04] so I'd like to try to figure out how to correct that [18:04] IMO we should encourage people to specialise more in triage - that would help people build up their expertise faster and build working relationships with developers [18:05] IOW specialise in a subset of packages [18:05] I think it could be a good thing to get people in bug-control who specialise in areas to become heads of bug sections who can act as general go betweens for bug-squad and devs. [18:05] bug reporters generally like to know that they have somebody knowledgeable on the other end of the line - nobody likes to feel as if they're being dealt with by a support firewall [18:05] specialisation is likely to improve that [18:06] davmor2: right we should start with bug-control and ask people to adopt certain packages [18:06] does marking bugs invalid require bugcontrol? [18:06] hence my proposal for a separate meeting about that topic [18:06] cjwatson: no it doesn't [18:07] hmm, shame [18:07] There are a lot of bug reports that are unworkable [18:07] cjwatson: no but having someone you can quickly check with that it is the right thing to do wouldn't harm [18:07] bdmurray: agreed, and I have no objection to triaging those fairly aggressively [18:08] bdmurray: my concern is more about the ones that are just fine, but somebody comes along who doesn't understand that they're just fine [18:08] Maybe adding something to the description would help? [18:09] um [18:09] in most of these cases, the description is a perfectly adequate description of the problem [18:10] I don't want to have to go editing lots of bugs to say "please don't close this bug" in them. (actually sometimes if you do that people close it anyway.) I want people not to close bugs that they don't understand., [18:10] * ScottK agrees understanding should preceed action. [18:11] it's just fine for bugs to be closed when there's just not enough in them to proceed, but at present, bug triagers are closing much more than that [18:11] and I honestly think that this is a flaw in triage, not a flaw in the bugs === pgraner is now known as pgraner-afk [18:11] to extend the triage metaphor, it's a bit like nurses telling everyone to go home and take an aspirin :-) [18:11] rather than understanding which ones need to be seen by doctors [18:12] BTW I'm not saying that anyone here is doing this! but it is happening [18:12] If only there were enough well qualified nurses ;) [18:13] and of course if only there were enough doctors, then we'd have less of a backlog of patients [18:13] OK, let's start by encouraging more specialisation and see where that takes us [18:13] indeed! [18:13] I sometimes feel as if the penalty for not fixing all your bugs quickly enough is that you have to spend all your time making sure they stay open [18:13] which is an interesting approach to incentivisation, but seems in the end to be counterproductive :) [18:13] I propose a bug-control meeting on April 16th at 18.00UTC [18:14]