15:03:54 #startmeeting Bugzappers meeting 2010/03/16 15:03:55 Meeting started Tue Mar 16 15:03:54 2010 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:03:56 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:04:02 #topic gathering 15:04:06 morning everyone...count off! 15:04:13 * mcepl is here 15:04:14 Hi Adam ;) 15:04:21 * Tech33 mutters to himself in the corner 15:04:52 alright, now go forth and ravage Middle Earth... 15:04:56 ...whoops, sorry, wrong meeting 15:05:12 Greetings 15:05:17 hey beland 15:05:19 I do that at night :) 15:06:39 alrighty then 15:06:47 #topic previous meeting follow-up 15:07:15 we just had one action item last week, and it's beland's 15:07:19 Hi guys 15:07:28 beland: we had you down to do some updates to the Rawhide wiki page - you got that done, right? 15:07:34 Yup, and then some. 15:07:36 hey iarlyy - we're just getting started 15:07:45 beland: awesome, fill us in if you like 15:08:21 Well [[Releases/Rawhide]] and [[Releases/Branched]] (which is new) are updated to reflect No Frozen Rawhide. 15:08:30 As is the Fedora Release Life Cycle page. 15:09:00 yay 15:09:08 There was a proposal to reorganize the Rawhide page into several smaller pages, which I'm not personally in favor of, but I have a link to a draft... 15:09:17 right, that was from jlaska I believe 15:09:33 yeah, I'm to blame for that 15:09:41 https://fedoraproject.org/wiki/User:Jlaska/Draft 15:09:59 #info beland has updated http://fedoraproject.org/wiki/Releases/Rawhide and http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle, and created http://fedoraproject.org/wiki/Releases/Branched, to reflect No Frozen Rawhide 15:10:19 #info jlaska has a proposal to split the Rawhide page into smaller pages - https://fedoraproject.org/wiki/User:Jlaska/Draft 15:10:40 i think jlaska and I discussed his draft before and I was sort of with beland, given that we initially created the Rawhide page by combining some smaller pages :) 15:10:46 I've not put much time into cleaning the draft up ... but my intent was to not detail the tons of different things about rawhide on the rawhide page itself, but instead link to specific pages for Installing Rawhide, Developing Rawhide, Testing rawhide etc... 15:10:48 Ah. 15:10:57 for me, it seems like a scary page to point people to 15:11:08 and we do a lot of pointing to that page (looking at the "What links here") 15:11:11 We'd need parallel pages for Branched, unless you combined the two in each subpage. 15:11:11 anyone else have a quick opinion? 15:11:24 beland: yeah exactly 15:12:17 beland: like I said earlier, this could just be how my brain operates ... but I've never been a fan of larger pages that require too much scrolling 15:12:41 jlaska, many users think like you... 15:13:08 I think if someone comes at the page with fresh eyes, they could probably streamline it and make it a bit less scary. 15:13:10 my take is that large pages are bad if you might not need all the info on them 15:13:22 I can keep playing around with reorganizing in my spare time ... until I have something to show in draft form, it's hard to discuss 15:13:23 front page be too objective and linking for subpages containing more information about users are looking for 15:13:28 beland: yeah, i said that too, at present the big page is mostly just a hybrid of two or three old pages, we didn't really prune it down when we made it 15:14:00 It does have a nice table of contents right at the top, so if it's clear which section has the info you are interested in, you can go directly there. 15:14:34 If you aren't sure, you can just read through or do a text search, which is a bit easier than opening a bunch of links and reading all of them. 15:14:57 by otherside when we have many pages, the work to keep all updated is increased... my little opinion 15:15:22 shall we say 'patches welcome'? =) 15:15:24 all good points. I'm just happy someone had the time and was able to update these pages! 15:15:40 adamw: exactly, I'm not going to push until I have a decent draft worth comparing with 15:15:49 beland: so thank you :) 15:15:54 * beland bows 15:16:08 * jlaska sounds the trumpets 15:16:18 #agreed rawhide pages can still be improved, please send proposals to the list 15:16:19 Thanks to everyone who answered my questions, so now we all know what the heck is going on. 8) 15:16:47 alrighty, next up, thanks again to beland for the reminder... 15:16:57 #topic what to do about Target trackers 15:17:18 so, yeah, we have these 'Target' trackers - F12Target, F13Target etc 15:17:30 these are supposed to be for bugs which aren't quite blockers but which we'd really like to fix before release 15:18:12 in my experience they're fairly useless lately. no-one really seems to afford them higher priority than any other bug. what do you folks feel? 15:18:27 I was looking at older ones; we have outstanding bugs going all the way back to FC5. 15:18:43 In practice, they don't seem to be working well. 15:19:15 i think mostly we have so many blockers to work on no-one has time to do any 'special' work on target bugs 15:20:17 adamw: we have fedora-x-target bug which I am moving to every new FXTarget, that could be one way; other way is just to remove it after FX is released, but it might be useful? I don't know 15:20:18 jlaska: wdyt? 15:20:39 should target bugs considered like a Blocker but with less priority, is it the point? 15:20:39 * jlaska read 15:21:09 iarlyy: yeah, basically it winds up being used as a dump for bugs we drop from the blocker list but feel bad about. i think the theory is that when you've fixed all your blockers, then you work on target bugs, heh. 15:21:14 adamw: agreed ... I don't think having those Trackers adds value anywhere 15:21:53 if it's somethign that's critical to the release, I would think we'd have a note in the criteria about it 15:22:11 my thought was just to ditch them 15:22:16 do the Target bugs offer a place where you put bugs you aren't sure about? 15:22:32 If you aren't sure, you're supposed to nominate as blocker. 15:22:34 yeah 15:22:40 right on 15:22:49 i don't think it'd work very well if someone thought 'hmm, i'm not sure this is a blocker, i'll put it on target' 15:23:09 adamw: no, I don't think random joe bugzapper should put bugs there 15:23:19 my thoughts as well 15:23:59 It's also a place where users express their yearnings to have their pet bugs fixed in a timely fashion. Except that it doesn't actually seem to work. 15:23:59 perhaps the *Target bugs worked best in a world without specific release criteria to debate/review 15:24:26 beland: perhaps we can direct those bugs to area specific lists ... e.g. F13VirtBlocker 15:24:28 our options are 'fix it or dump it', i guess, but i'm not sure i see a really good use we could 'fix' the system to work with 15:24:45 in practice we don't have devs with acres of time thinking 'gee, if only I knew which bugs I should fix first!' 15:25:02 it's hard enough to herd them into working on blockers =) 15:25:26 If Target bugs go away, it's really just "file it as normal and set the Severity appropriately." 15:25:46 beland: and we have a fairly solid definition of severity to direct testers to 15:25:48 yeah, that's another point; severity addresses much the same area 15:26:11 so, should we work up a proposal to just kill the Target blockers, and float it on -devel? 15:26:21 And votes, if anyone ever pays attention to those. 15:26:42 Sure. Are we proposing just not creating any more for F14, or scrubbing the existing ones out of existance? 15:26:57 either way, i dunno. wdyt? 15:27:14 Untidiness bothers me, but so does destroying information. 15:27:14 the question don't leave from my mind, why targets hasn't attention today? 15:27:38 Package maintainers have the freedom to ignore them, and they do so. 15:28:47 Just because bug reporters and triagers say "it's really important we fix this list of bugs" doesn't mean that aligns with the maintainer's personal priorities or available time. 15:28:59 adamw: well, certainly we should kill without any further replacement FedoraXTarget for X <= 12 15:31:04 okay, so does someone want to take point on this one? 15:31:21 i'll do it if no-one else wants to, but feel free to volunteer if you like 15:31:40 * adamw was watching Buffy last night and thoroughly approves of the Mean Headmaster's approach to volunteering 15:32:46 If developers don't adopt the idea, it will at least raise awareness about the lists. 15:33:20 right, floating the idea is a win-win 15:33:29 if they want to keep the lists we get to tell them to fix more of the bugs on the lists, heh 15:35:30 well i guess i'm doing it then! okay 15:35:42 #action adamw to float a proposal to drop the Target bug trackers 15:36:08 #agreed the Target trackers aren't much use, we think we might as well just remove them 15:36:15 alright, next up... 15:36:40 #topic what to do about crasher bugs http://bugzilla.redhat.com/show_bug.cgi?id=543165 and http://bugzilla.redhat.com/show_bug.cgi?id=538207 15:37:07 so these also come from beland's email - these are very commonly-filed crasher bugs, right? 15:37:10 So these two crash bugs in F12 that are affecting hundreds of people. I would nominate these as blockers, but the release is already out. It just seems like the sort of thing that someone who is In Charge of the entire release would look at and say, "oh, that should get fixed ASAP". Except it's unclear if that someone exists. 15:37:24 Yes, they are at the top of the most reported bugs list, by far: 15:37:30 So these two crash bugs in F12 that are affecting hundreds of people. I would nominate these as blockers, but the release is already out. It just seems like the sort of thing that someone who is In Charge of the entire release would look at and say, "oh, that should get fixed ASAP". Except it's unclear if that someone exists. 15:37:48 (sorry) https://bugzilla.redhat.com/duplicates.cgi?sortby=count&reverse=1&product=Fedora&maxrows=100&changedsince=7 15:38:35 okay 15:38:44 Now that ABRT is working well, I and everyone else who has experienced this crash gets an email everytime someone new crashes. 15:39:52 so i'm thinking we should definitely talk to the mozilla maintainers about this 15:39:54 and maybe also to upstream 15:40:49 do you know if there's upstream equivalents for either of these reports? 15:40:52 if I may, and since I'm currently the primary triager, the majority of those crashes are crashes that people don't even know happen, until abrt says it did 15:40:53 Think they're just lost in the noise of all the Mozilla bugs? 15:41:03 and no, there are not, that I could find 15:41:04 Yes, they are crashes-on-close. 15:41:21 I asked about upstream reports in the bugs, and no one replied. 15:41:30 Tech33: you always 'may' =) thanks for the input 15:42:15 * adamw is tempted to say 'let's put an exception in abrt and pretend it's not happening' =) 15:42:57 Tech33: there's no rules about who can talk when in meetings, if you have something to say just say it - that goes for everyone 15:44:12 understood, it's just my way 15:44:24 alright, so i'd definitely say we should talk to the firefox maintainers as a first step. again, i can do that, or it'd be great if anyone else wants to 15:44:48 it'll have to be you (or mcepl) 15:45:26 hey, sorry, I got lost 15:45:30 * mcepl is reading backlog 15:45:31 * Tech33 has to step away, bbiab (I'll read the minutes) 15:46:12 Tech33_away: if you mean because the maintainers work for Red Hat, I'd hope not. this is a Fedora project issue, being a Fedora project member should be enough, doesn't matter whether you're @redhat. :) 15:46:13 I'm sort of curious whether any developers are watching the Most Reported list, or take it into account when prioritizing bugs. 15:46:27 beland: yeah, that's a point - it may be worth promoting that list a bit 15:46:27 Or for that matter, whether they're overwhelmed with new ABRT bugs. 15:46:31 beland: i wasn't really aware of it 15:46:56 i don't _think_ devs are overwhelmed in general, but it may be different for firefox, which is a) big, b) popular and c) quite crashy. 15:47:07 It's a very crude measure of how many people are experiencing a bug; you can also count "me too" comments or CC: list length. 15:47:51 Some components are now 80% abrt crashes and 20% manually reported bugs (as far as NEW bugs go). 15:48:08 * mcepl i will certainly talk with stransky (FF maintainer) about these 15:48:29 I was wondering if at some point, we'd be able to say "a new version of this software has been released, any crashers for older versions are hereby closed until ABRT reports a new crash" 15:48:39 #action mcepl talk with FF maintainers about bug 543165 and bug 538207 15:48:48 Or if that's best to leave up to the normal EOL process. 15:49:08 beland: i think we can leave it unless we get some really bad complaints; from what i've seen, complaints about abrt have died down rather lately 15:49:43 Change is always loud that way. 15:50:30 * mcepl is talking with stransky now 15:50:41 Awesome. 15:50:56 okay 15:51:02 let's leave this with mcepl for follow-up next week 15:51:09 moving on, as i want to get through everything... 15:51:28 #topic what to do about ASSIGNED-not-Triaged bugs 15:51:48 mcepl mentioned this just before the meeting - he has a search for bugs which are in ASSIGNED status but not Triaged keyword 15:52:14 https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Fedora%20AS%20unTriaged&sharer_id=74116; 15:52:29 (quite certainly a lot of false positives there ... I see all Packaging Reviews now) 15:52:42 #link https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Fedora%20AS%20unTriaged&sharer_id=74116 15:53:06 my answer would simply be 'nothing', as this isn't necessarily wrong 15:53:21 remember the whole point of us not using ASSIGNED to mean Triaged any more was so that ASSIGNED can be used by the maintainers 15:53:54 to just take a completely random example - i clicked on a random bug from the list and it was https://bugzilla.redhat.com/show_bug.cgi?id=573252 15:53:55 OK I can take it ... and will fix my bugs 15:54:01 look at the history; it's the maintainer who set it to ASSIGNED 15:54:12 so all is as it should be there 15:54:55 just looked at three more bugs, they were all the same 15:55:37 oh, the other case where it happens is if a bug is set to MODIFIED but turns out not to be broken 15:55:54 it would be nice if Bugzilla let you set it back to whatever status it had before being changed, rather than always going to ASSIGNED, but i don't think that's really a huge issue 15:56:02 er, s/broken/fixed/ 15:56:24 erf. i got that wrong! i meant, if it's closed but then re-opened, it goes to ASSIGNED 15:56:41 I think the agreement was that Triaged was the definitive answer to "should I bother with this bug?" 15:57:00 but whatever 15:57:33 well, Triaged is the definitive answer to 'has this bug been triaged' 15:57:44 ASSIGNED is at the maintainer's discretion, they can use it however they choose 15:58:26 And triagers should only be looking at NEW bugs, anyway. 15:58:28 but yeah...going through that list and clicking at random i haven't seen any cases where the bug obviously ought to be marked Triaged and isn't, or obviously ought to *not* be ASSIGNED... 15:58:31 anyone else have a take? 15:58:32 OK, I will think about it; withdrawing an agenda item 15:58:44 for now 15:59:17 by all means raise it again next week if you find that some of the bugs on the list actually are problematic 15:59:26 i only went through a dozen or so, may have just got lucky =) 16:00:11 alright then...that's everything we had on the agenda I think 16:00:16 did I miss anyone's topic? 16:00:38 #agreed there doesn't seem to be a problem with ASSIGNED-not-Triaged bugs from a quick eyeball of the list, mcepl will review and bring up again at a future meeting if he finds problems 16:01:55 alright, quick open floor 16:01:58 #topic open floor 16:02:14 Bertrand Juglas raised a question on the list but I don't see him here... 16:02:36 bertrand, are you out there? anyone else have an open floor topic? 16:03:31 nops from me 16:05:42 alright then! thanks for coming everyone 16:05:50 now go forth and ravage 16:05:53 #endmeeting