15:03:54 <adamw> #startmeeting Bugzappers meeting 2010/03/16
15:03:55 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:02 <adamw> #topic gathering
15:04:06 <adamw> morning everyone...count off!
15:04:13 * mcepl is here
15:04:14 <Kyril> Hi Adam ;)
15:04:21 * Tech33 mutters to himself in the corner
15:04:52 <adamw> alright, now go forth and ravage Middle Earth...
15:04:56 <adamw> ...whoops, sorry, wrong meeting
15:05:12 <beland> Greetings
15:05:17 <adamw> hey beland
15:05:19 <Tech33> I do that at night :)
15:06:39 <adamw> alrighty then
15:06:47 <adamw> #topic previous meeting follow-up
15:07:15 <adamw> we just had one action item last week, and it's beland's
15:07:19 <iarlyy> Hi guys
15:07:28 <adamw> beland: we had you down to do some updates to the Rawhide wiki page - you got that done, right?
15:07:34 <beland> Yup, and then some.
15:07:36 <adamw> hey iarlyy - we're just getting started
15:07:45 <adamw> beland: awesome, fill us in if you like
15:08:21 <beland> Well [[Releases/Rawhide]] and [[Releases/Branched]] (which is new) are updated to reflect No Frozen Rawhide.
15:08:30 <beland> As is the Fedora Release Life Cycle page.
15:09:00 <adamw> yay
15:09:08 <beland> 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 <adamw> right, that was from jlaska I believe
15:09:33 <jlaska> yeah, I'm to blame for that
15:09:41 <beland> https://fedoraproject.org/wiki/User:Jlaska/Draft
15:09:59 <adamw> #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 <adamw> #info jlaska has a proposal to split the Rawhide page into smaller pages - https://fedoraproject.org/wiki/User:Jlaska/Draft
15:10:40 <adamw> 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 <jlaska> 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 <beland> Ah.
15:10:57 <jlaska> for me, it seems like a scary page to point people to
15:11:08 <jlaska> and we do a lot of pointing to that page (looking at the "What links here")
15:11:11 <beland> We'd need parallel pages for Branched, unless you combined the two in each subpage.
15:11:11 <adamw> anyone else have a quick opinion?
15:11:24 <jlaska> beland: yeah exactly
15:12:17 <jlaska> 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 <iarlyy> jlaska, many users think like you...
15:13:08 <beland> 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 <adamw> my take is that large pages are bad if you might not need all the info on them
15:13:22 <jlaska> 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 <iarlyy> front page be too objective and linking for subpages containing more information about users are looking for
15:13:28 <adamw> 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 <beland> 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 <beland> 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 <iarlyy> by otherside when we have many pages, the work to keep all updated is increased... my little opinion
15:15:22 <adamw> shall we say 'patches welcome'? =)
15:15:24 <jlaska> all good points.  I'm just happy someone had the time and was able to update these pages!
15:15:40 <jlaska> adamw: exactly, I'm not going to push until I have a decent draft worth comparing with
15:15:49 <jlaska> beland: so thank you :)
15:15:54 * beland bows
15:16:08 * jlaska sounds the trumpets
15:16:18 <adamw> #agreed rawhide pages can still be improved, please send proposals to the list
15:16:19 <beland> Thanks to everyone who answered my questions, so now we all know what the heck is going on. 8)
15:16:47 <adamw> alrighty, next up, thanks again to beland for the reminder...
15:16:57 <adamw> #topic what to do about Target trackers
15:17:18 <adamw> so, yeah, we have these 'Target' trackers - F12Target, F13Target etc
15:17:30 <adamw> 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 <adamw> 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 <beland> I was looking at older ones; we have outstanding bugs going all the way back to FC5.
15:18:43 <beland> In practice, they don't seem to be working well.
15:19:15 <adamw> 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 <mcepl> 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 <adamw> jlaska: wdyt?
15:20:39 <iarlyy> should target bugs considered like a Blocker but with less priority, is it the point?
15:20:39 * jlaska read
15:21:09 <adamw> 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 <jlaska> adamw: agreed ... I don't think having those Trackers adds value anywhere
15:21:53 <jlaska> 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 <adamw> my thought was just to ditch them
15:22:16 <jlaska> do the Target bugs offer a place where you put bugs you aren't sure about?
15:22:32 <beland> If you aren't sure, you're supposed to nominate as blocker.
15:22:34 <adamw> yeah
15:22:40 <jlaska> right on
15:22:49 <adamw> 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 <mcepl> adamw: no, I don't think random joe bugzapper should put bugs there
15:23:19 <jlaska> my thoughts as well
15:23:59 <beland> 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 <jlaska> perhaps the *Target bugs worked best in a world without specific release criteria to debate/review
15:24:26 <jlaska> beland: perhaps we can direct those bugs to area specific lists ... e.g. F13VirtBlocker
15:24:28 <adamw> 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 <adamw> 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 <adamw> it's hard enough to herd them into working on blockers =)
15:25:26 <beland> If Target bugs go away, it's really just "file it as normal and set the Severity appropriately."
15:25:46 <jlaska> beland: and we have a fairly solid definition of severity to direct testers to
15:25:48 <adamw> yeah, that's another point; severity addresses much the same area
15:26:11 <adamw> so, should we work up a proposal to just kill the Target blockers, and float it on -devel?
15:26:21 <beland> And votes, if anyone ever pays attention to those.
15:26:42 <beland> Sure. Are we proposing just not creating any more for F14, or scrubbing the existing ones out of existance?
15:26:57 <adamw> either way, i dunno. wdyt?
15:27:14 <beland> Untidiness bothers me, but so does destroying information.
15:27:14 <iarlyy> the question don't leave from my mind, why targets hasn't attention today?
15:27:38 <beland> Package maintainers have the freedom to ignore them, and they do so.
15:28:47 <beland> 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 <mcepl> adamw: well, certainly we should kill without any further replacement FedoraXTarget for X <= 12
15:31:04 <adamw> okay, so does someone want to take point on this one?
15:31:21 <adamw> 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 <beland> If developers don't adopt the idea, it will at least raise awareness about the lists.
15:33:20 <adamw> right, floating the idea is a win-win
15:33:29 <adamw> 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 <adamw> well i guess i'm doing it then! okay
15:35:42 <adamw> #action adamw to float a proposal to drop the Target bug trackers
15:36:08 <adamw> #agreed the Target trackers aren't much use, we think we might as well just remove them
15:36:15 <adamw> alright, next up...
15:36:40 <adamw> #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 <adamw> so these also come from beland's email - these are very commonly-filed crasher bugs, right?
15:37:10 <beland> 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 <beland> Yes, they are at the top of the most reported bugs list, by far:
15:37:30 <beland> 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 <beland> (sorry) https://bugzilla.redhat.com/duplicates.cgi?sortby=count&reverse=1&product=Fedora&maxrows=100&changedsince=7
15:38:35 <adamw> okay
15:38:44 <beland> 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 <adamw> so i'm thinking we should definitely talk to the mozilla maintainers about this
15:39:54 <adamw> and maybe also to upstream
15:40:49 <adamw> do you know if there's upstream equivalents for either of these reports?
15:40:52 <Tech33> 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 <beland> Think they're just lost in the noise of all the Mozilla bugs?
15:41:03 <Tech33> and no, there are not, that I could find
15:41:04 <beland> Yes, they are crashes-on-close.
15:41:21 <beland> I asked about upstream reports in the bugs, and no one replied.
15:41:30 <adamw> 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 <adamw> 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 <Tech33> understood, it's just my way
15:44:24 <adamw> 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 <Tech33> it'll have to be you (or mcepl)
15:45:26 <mcepl> 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 <adamw> 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 <beland> 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 <adamw> beland: yeah, that's a point - it may be worth promoting that list a bit
15:46:27 <beland> Or for that matter, whether they're overwhelmed with new ABRT bugs.
15:46:31 <adamw> beland: i wasn't really aware of it
15:46:56 <adamw> 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 <beland> 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 <beland> 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 <beland> 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 <mcepl> #action mcepl talk with FF maintainers about bug 543165 and bug 538207
15:48:48 <beland> Or if that's best to leave up to the normal EOL process.
15:49:08 <adamw> 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 <beland> Change is always loud that way.
15:50:30 * mcepl is talking with stransky now
15:50:41 <beland> Awesome.
15:50:56 <adamw> okay
15:51:02 <adamw> let's leave this with mcepl for follow-up next week
15:51:09 <adamw> moving on, as i want to get through everything...
15:51:28 <adamw> #topic what to do about ASSIGNED-not-Triaged bugs
15:51:48 <adamw> 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 <mcepl> https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Fedora%20AS%20unTriaged&sharer_id=74116;
15:52:29 <mcepl> (quite certainly a lot of false positives there ... I see all Packaging Reviews now)
15:52:42 <adamw> #link https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Fedora%20AS%20unTriaged&sharer_id=74116
15:53:06 <adamw> my answer would simply be 'nothing', as this isn't necessarily wrong
15:53:21 <adamw> 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 <adamw> 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 <mcepl> OK I can take it ... and will fix my bugs
15:54:01 <adamw> look at the history; it's the maintainer who set it to ASSIGNED
15:54:12 <adamw> so all is as it should be there
15:54:55 <adamw> just looked at three more bugs, they were all the same
15:55:37 <adamw> 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 <adamw> 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 <adamw> er, s/broken/fixed/
15:56:24 <adamw> erf. i got that wrong! i meant, if it's closed but then re-opened, it goes to ASSIGNED
15:56:41 <mcepl> I think the agreement was that Triaged was the definitive answer to "should I bother with this bug?"
15:57:00 <mcepl> but whatever
15:57:33 <adamw> well, Triaged is the definitive answer to 'has this bug been triaged'
15:57:44 <adamw> ASSIGNED is at the maintainer's discretion, they can use it however they choose
15:58:26 <beland> And triagers should only be looking at NEW bugs, anyway.
15:58:28 <adamw> 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 <adamw> anyone else have a take?
15:58:32 <mcepl> OK, I will think about it; withdrawing an agenda item
15:58:44 <mcepl> for now
15:59:17 <adamw> 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 <adamw> i only went through a dozen or so, may have just got lucky =)
16:00:11 <adamw> alright then...that's everything we had on the agenda I think
16:00:16 <adamw> did I miss anyone's topic?
16:00:38 <adamw> #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 <adamw> alright, quick open floor
16:01:58 <adamw> #topic open floor
16:02:14 <adamw> Bertrand Juglas raised a question on the list but I don't see him here...
16:02:36 <adamw> bertrand, are you out there? anyone else have an open floor topic?
16:03:31 <iarlyy> nops from me
16:05:42 <adamw> alright then! thanks for coming everyone
16:05:50 <adamw> now go forth and ravage
16:05:53 <adamw> #endmeeting