15:11:00 #startmeeting BugZappers Weekly Meeting 15:11:00 Meeting started Tue Nov 24 15:11:00 2009 UTC. The chair is tk009. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:11:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:11:11 #chair adamw 15:11:11 Current chairs: adamw tk009 15:12:11 happy meeting 15:12:17 #topic roll call 15:12:24 who is here 15:12:29 * johe takes a seat 15:12:44 as usually... I'm here = ) 15:13:10 i'm present 15:13:23 * mcepl is here 15:13:57 Hi all, I am as well (new triager ... for few weeks ), nice to meet you all 15:13:57 #topic - Housekeeping 15:14:06 hi everyone 15:14:17 hello hdia and welcome 15:14:24 hi hdia 15:14:30 thanks ;-) 15:14:33 :) 15:15:11 the first thing in housekeeping is ongoing, have a look at the link. 15:15:13 * SMParrish_mobile here 15:15:28 It is really just a reminder 15:16:22 #topic - Housekeeping - Updating the Components and Triagers List 15:17:05 this is something from last week and something missed in housekeeping 15:17:20 #link https://fedoraproject.org/wiki/BugZappers/HouseKeeping/OnGoing 15:17:21 adamw you wanted this added from last week 15:17:30 thanks 15:17:32 #link https://fedoraproject.org/wiki/BugZappers/HouseKeeping/FirstDayDevel 15:17:50 i wanted it added? really? 15:18:08 in the past before the components list we flushed the triagers list and created a new one for the next cycle 15:18:14 yes really 15:18:23 i think it got mentioned for the blocker updates 15:18:36 but i didn't really mean anything specific about the triagers list... 15:18:43 one sec 15:18:56 i remember we had a debate about what to do with it for f11 as well, what did we decide in the end? 15:19:35 15:35:54 i think we did it based off a critical path snapshot from a few months back, we should probably check it every few months against a new critical path snapshot 15:19:40 15:35:57 OK 15:19:43 15:36:05 maybe stick that on the agenda for next week... 15:19:50 * Tech33 is here 15:20:33 that must've been that OTHER adamw :) 15:20:34 ringing any bells? =) 15:20:34 hi tech33 15:20:47 i was thinking more of the component list actually 15:20:59 yes and that is what we are talking about here 15:21:09 oh. i thought you were talking about the triagers. 15:21:12 that is should be check/updated 15:21:23 well they are tied together 15:21:39 the wiki has outdated info 15:21:47 that we flush the triagers 15:21:50 well yeah but you can quite easily adjust just one or t'other. 15:21:50 anyway. 15:22:03 so. um. like i said. what did we do for f11? 15:22:34 I don't recall off hand, but I know its in the meeting minutes 15:22:43 I will have to look 15:23:32 so do we want to change the info on the wiki about flushing the triagers 15:23:43 yeah probably 15:23:47 and who wants to do the component list updating? 15:23:53 i think we should carry over the list but prune people we know to be inactive 15:24:00 arxs did the component list last time, i believe 15:24:10 he did but has been AWOL of late 15:24:11 clearing the things... inactive triagers, isn't? 15:24:12 has anyone seen him around lately? 15:24:22 iarlyy: well we kinda need to keep the component list updated too 15:24:30 it's based on the critical path package list now and that can change 15:24:55 hmm... is right 15:24:58 last time niels posted to the list was two months ago 15:25:12 should we try and poke him for whatever tools / commands he used to generate the list? 15:25:29 I will figure out how we did it last tie and we can bring this up next meeting 15:25:43 and aybe someone will volunteer to do it 15:25:51 yes no? 15:26:02 yes 15:26:34 ok 15:26:36 sounds good, thanks! 15:26:44 maybe at http://fedoraproject.org/wiki/User:Mcepl 15:26:50 i think it was mostly 'arxs went away and came back with a list' though :) 15:26:54 there is the command needed 15:27:01 that was the old list 15:27:45 mcepl should probably update that page... 15:27:52 * mcepl was intentionally silent ... this was really something around F10 15:28:03 tk009: you may want to check with...i think skvidal or wwoods for the script which dynamically generates the critpath list each day 15:28:13 moreover this doesn't know anything about critical components 15:28:15 adamw: it's in autoqa now 15:28:17 yes I will 15:28:19 rats_sanity? 15:28:19 skvidal: ah thanks 15:28:23 something like that 15:28:41 adamw: git clone git://git.fedorahosted.org/git/releng 15:28:48 it's in the scripts dir you can run it yourself 15:28:58 * poelcat tried yesterday 15:28:59 if it's in both autoqa and releng git, which is canonical? 15:29:08 * poelcat can't speak for autoqa 15:29:59 well there we go then =) thanks poelcat 15:30:18 #action tk009 to investigate methods for updating the components list 15:30:34 moving on? 15:30:40 for updating the active triagers...perhaps someone can go through and come up with a list of those who don't seem to be doing much? 15:30:49 then we can ping them directly and ask them to say whether they're still active 15:31:09 I can do that 15:31:18 i can do it too if it'd be too much load for you to do both? 15:31:34 tk009, if need help with this... I can help too 15:31:34 I don't think there is a problem 15:31:39 I can do them 15:31:53 paint dry very slowly these days =) 15:32:07 there are many inactive zappers? 15:32:08 thanks iarlyy 15:32:18 I couldn't tell you yet 15:32:27 I know how to find out though 15:32:40 hmm... right 15:32:54 #topic - Mentors 15:33:15 I added this one because I saw it mentioned that cepl was willing to mentor new members 15:33:22 mcepl* 15:33:46 this is a good idea that we should all try our best to do 15:33:51 tk009: I meant sitting on #fedora-bugzappers and letting my wisdom to be known 15:33:57 evern if all you can give is 5 minutes 15:33:59 no, I didn't actually 15:34:11 yes, I am willing to mentor really ... I did it with 15:34:18 okay correction then hehe 15:34:31 mcepl: well you did but it was rather a long time ago :) 15:34:40 (say you were willing to mentor that is) 15:34:54 adamw: critpath list is generated as part of rawhide build - check the logs 15:35:00 I will say, #Fedora-BugZappers *can* be a quiet channel at times 15:35:05 Francois Cami and it was good, but he is kind of MIA lately 15:35:23 e.g. http://kojipkgs.fedoraproject.org/mash/rawhide-20091124/logs/critpath.txt 15:35:26 adamw: not true, there are still some people who pop up on me 15:35:30 that's today's critpath. 15:35:31 mcepl: he's not really MIA, he's just busy with other stuff 15:35:40 thanks wwoods 15:35:40 yes, that's why I said kind of 15:35:41 wwoods: thanks 15:36:03 Tech33: it's mostly because once you get into the swing of bugzapping there's not a lot of stuff you need to ask 15:36:06 if you know about somebody who is willing to spend some real time and effort but doesn't know how .. my nick is mcepl 15:36:10 Tech33: and it's not really a hang-out-and-chat channel 15:36:15 well this is something we could and should work on 15:36:27 Tech33: but you can always ping one of the more veteran members and they'll be happy to help if they're around 15:36:52 even things like saying hi to new members on the list 15:37:06 I would like to see others trying to do more of that 15:37:41 I always effort myself to do that... 15:37:54 I know its hard with our limited numbers but we still need to make more effort 15:37:55 well i dunno, you can look at it two ways 15:38:06 it's nice to say hi but then if everyone says hi to every new member it'll clutter up the list a bit :) 15:38:14 it may be nice to do it via private email (not to list) 15:38:26 people have done that to me when i joined other groups, that was nice 15:38:27 fine as long as its being done 15:38:45 I emailed you private 15:38:51 remember 15:38:53 =P 15:39:18 okay so maybe not fill the list up 15:39:32 but two or three people doesn't hurt anything 15:40:03 anything to add on this one? 15:40:44 well, we're supposed to be talking about mentoring =) 15:41:01 do any of you newer members think mentoring would be useful for you? 15:41:04 well I dont hear anyone saying yes that needs to be done 15:41:22 i thought it was kinda implied :) 15:41:24 i think i would. 15:41:58 daelious: cool. do you have any idea what kind of components you'd like to work on yet? 15:42:05 (may affect who would be the best mentor) 15:42:06 I would of liked to have someone to help me along when I started 15:42:45 * mcepl is getting impatient ... we have too little time and too much to talk about 15:42:55 adamw: yes and i have contacted them just not sure where to go. 15:43:06 daelious: which ones? 15:43:17 it was pretty daunting at the beginning, so yes, even 15 minutes would have helped 15:43:36 well, i think it works great with you all being metors of some kind, the information who is doing what would b nice 15:43:41 daelious: like i said, it helps to see who would be the best mentor if we know what area to want to work in 15:43:51 johe: the Triagers and Components page lists who works on which bits 15:43:59 adamw: i will discuss in the main chat so the meeting can continue 15:44:09 yes but neither you or yself are on that list adamw 15:44:21 adamw, well, dont think that it is that up to date, or? 15:44:24 okay we'll move on 15:44:37 tk009: yeah i need to update it :) 15:44:40 johe: it's not far off 15:44:45 #Topic - New Members of the Bugzappers 15:44:55 daelious: okay, thanks! 15:45:14 This is jsut a heads up that there have been a lot of new members added to our little group 15:45:29 8 for Noveber alone 15:45:41 yayyyy!!! Thanks everybody, I cannot believe anybody is so crazy to help with this mess! 15:45:51 yep, woo new members 15:45:52 :) 15:45:56 yes thanks you new members for helping out 15:46:06 mcepl: Yes ! here we are lol 15:46:25 #Topic - Membership Request Removals 15:46:31 how I know how long I joined to the group? 15:46:36 I added this topic just so people know what is going on 15:46:55 iarlyy look at the triagers group info 15:47:03 it will say date added =) 15:47:26 (or the grey hair maybe) just joking 15:47:44 so I am removed two project memebers that have requested membership in the bugzappers 15:47:46 (or no hair) 15:47:49 removing rather 15:48:03 they did not complete the requirements to join 15:48:41 again this is just so people know what s going on. Their names are not important so I wont mention them 15:48:58 just that I will remove their requests after the meeting 15:49:13 that's fine, i mostly do that silently when we get group requests without the rest of the process being completed =) 15:49:33 I wasnt sure I should bring it up 15:49:45 but I wanted you to know as well =) 15:49:52 it's fine, we trust you =) 15:49:57 beah 15:50:00 trust no one 15:50:02 =) 15:50:05 moving on 15:50:17 #topic - open floor 15:50:25 didn't we have a topic for mcepl's question? 15:50:34 yes I just noticed I missed it 15:50:41 and I have another one ... or more request to think 15:50:54 #chair mcepl 15:50:54 Current chairs: adamw mcepl tk009 15:51:01 you have the floor mcepl 15:51:06 do a #topic 15:51:09 for clarity :) 15:51:27 OK, so the situation is that bug being triaged is marked in two ways: in Fedora 11 it is ASSIGNED, in F12 and Rawhide it is keyword Triaged. Correct? 15:51:45 #topic marking bugs as triaged 15:51:48 mcepl: no 15:51:54 f11 and f12 are keyword Triaged 15:51:54 ok? 15:52:01 erf 15:52:02 F11????? 15:52:06 f11 and f12 are ASSIGNED 15:52:07 (sorry) 15:52:11 only f13 is keyword Triaged 15:52:25 f12 assigned..? 15:52:28 OK, now I am seriously confused ... but yes, you are right 15:52:38 I'm too 15:52:42 okay, to recap :) 15:52:43 I have been doing everything 'triaged' going forward does this mess us up? 15:52:49 (and I do it incorrectly ... I mark F12 with keyword) 15:52:57 heh, we should've notified better i guess :) 15:52:58 I too 15:53:02 what JUST happened is why this concept is a bad one 15:53:06 the plan was to switch _only_ for f13 and later 15:53:21 OK, so my plea ... could we just PLEASE unify on one method? 15:53:23 that's why we waited until f13 came out 15:53:25 I knew the plan I didn't follow it correctly 15:53:38 that is why i ask does that ess us up? 15:53:40 it wouldn't make sense to wait for f13 to come out and then start doing it for f12 too =) 15:53:46 like marking all ASSIGNED bugs (in whichever Fedora applicable) with keyword Triaged and then forget that there is such thing as status field? 15:54:02 so that's my proposal 15:54:15 i believe the argument against it during the initial discussions was that mass changes are fragile and easy to get wrong 15:54:29 there are so many related things (queries, filtering of emails, etc.) which are hard to make for dual system 15:54:32 but just for *adding* the Triaged keyword to all ASSIGNED bugs, i think that should probably be safe 15:54:50 and not marking them as ASSIGNED anymore 15:54:59 like the PK bug 15:55:06 right, but not changing existing ones back to NEW 15:55:07 I marked it 'traiged' 15:55:10 not assigned 15:55:12 yes 15:55:24 tk009: ASSIGNED is a status not a keyword 15:55:27 tentatively i think that should be ok 15:55:39 but we should run it by the bugzilla maintainer as it'd be a BIG operation 15:55:44 I know I just meant I didn't assign it 15:55:48 and possibly see if we can do it without generating ten thousand spam mails 15:55:54 yes, please 15:56:08 should I file a bug against Bugzilla product, or just ping dkl? 15:56:11 so... all current bugs as assigned we add Triaged keyword, ok? 15:56:15 yes 15:56:18 does anyone see a problem with mcepl's proposal? which is, to make it clear, to add the Triaged keyword to every ASSIGNED bug 15:56:25 and new bugs for f11 or f12... directly triaged 15:56:27 okay so if i undersatnd correctly, mecpl you want to change already triaged bugs? 15:56:28 in current bugzilla, for all releases 15:56:38 and mark with keyword only henceforth 15:56:40 or if f11 assigned and f12 only keyword 15:56:49 the only case would be if there were any reason to not do it 15:56:53 tk009: just add to them keyword Triaged 15:57:05 well there probably are bugs in ASSIGNED status which haven't really been 'triaged' 15:57:07 that would generate some mail 15:57:14 adamw: like???? 15:57:17 but i don't see that as a horrible problem, i don't think it'd have any practical ill-effects 15:57:17 I would agree adamwe 15:57:54 there are some problem add triaged keyword if bug already a keyword? 15:57:55 excluding FutureFeatures and anaconda bugs (or are they on the board now?) 15:57:56 mcepl: no concrete examples, i'm just working off murphy's law =) 15:58:01 sure 15:58:06 iarlyy: no, that shouldn't be a problem 15:58:44 is keyword a field you can query, so that you won't get two triaged entries? 15:58:51 yes 15:58:51 Tech33: yes 15:59:12 Tech33: the problem at present is that it's very hard to construct a bugzilla query which checks for all triaged bugs - i.e. which checks for _both_ triaging methods 15:59:17 which is why mcepl wants to simplify it 15:59:24 well, not 'very hard', 'apparently impossible' :) 15:59:26 I understand that 15:59:28 in advanced query you have field Keyword "contains/doesn't contain keyword" 15:59:56 adamw: you found a little bit of a way, but it is hopelessly brittle 15:59:59 and not complete 16:00:12 mcepl: so do you want to take an action item to contact dave lawrence? 16:00:16 yes 16:00:27 is it hash-action? 16:00:32 yep 16:00:56 #action mcepl contacts dkl to add Triaged keyword to all open ASSIGNED bugs excluding FutureFeatures and anaconda component (anything else?) 16:01:16 ake sure no spam mail 16:01:23 yes, of course 16:01:24 heh 16:01:27 we probably need to discuss anaconda with denise actually 16:01:34 as i believe andy is no longer triaging anaconda bugs 16:01:38 but better make that a next week topic 16:01:54 okay we are out of time my bad mcepl 16:02:04 anything else? 16:02:08 nop from me 16:02:09 OK, I have one tiny thing ... 16:02:09 yes 16:02:14 kk 16:02:30 i have a point 16:02:42 as a canary in the mine I see coming avalanche ... abrt bugs are getting out of hand (at least in Firefox world so far) ... we should think what to do with them 16:02:42 hdia, tell us 16:02:47 after mcepl hdia 16:02:54 howgh 16:03:00 #topic open floor: abrt dupe flood 16:03:09 i know that the abrt team is working on improving dupe detection 16:03:12 they are crazy at times 16:03:25 what can we do? 16:03:35 other than close them as we see them 16:03:37 I had 50+ bugs against Firefox & co.just during yesterday, and it won't get better. 16:03:42 there's a mail on devel-list from Karel Klic yesterday to that effect 16:03:47 we need to develop some tools or something 16:03:51 "I am working on the duplication detection these days. 16:03:51 I looked into your backtraces: it's obvious those are duplicates, 16:03:51 and the new code will catch them." 16:03:55 it should get better: see above 16:04:04 if abrt does better dupe detection itself, it won't file so many 16:04:19 slowly, and little bit ... Iwouldn't count on the problem being resolved completely 16:04:29 what i was thinking is we could ask the abrt guys if they can work with us / dave to provide some kind of script to retrospectively apply the new dupe detection to already-filed bugs 16:04:44 no, but it should improve. i don't want to be too pessimistic yet :) i think it's still at the 80/20 stage 16:04:47 nice diea 16:04:54 idea* 16:04:55 where they can probably get quite a lot of dupes with some fairly simple code 16:05:06 before we hit the stage of the 20% of 'hard' dupes which are more complex to detect 16:05:26 i'm a bit annoyed that abrt got implemented by default _without_ better dupe detection, to be honest, but that's water under the bridge :/ 16:05:50 it's one of those things that it was hard for us to realize before release since not many people were filing bugs 16:05:50 I am afraid, that in meanwhile will be completely sunk in dupes 16:06:03 well i'm happy to take an action item to talk to the abrt guys about my idea... 16:06:03 I specifically argued that abrt shouldn't be turned on until its dup detection was better *or* it was reporting things to something other than bugzilla 16:06:07 or both 16:06:08 does anyone have other ideas? 16:06:16 adamw: they tried ... hard ... but it is really difficult problem, so I wouldn't expect real solution fast. 16:06:21 this is why GNOME gave up on bug-buddy 16:06:30 mcepl: hum, ok :/ from what i'd read i was more optimistic than that 16:06:31 beasts like Firefox or OOo generate something which is almost impossible to decipher 16:07:19 trust me, folks @ Brno office are working hard on this in the last couple of months 16:07:35 yeah it's a really tough problem to solve 16:07:37 this will have to go to the list for further discussion I think 16:07:42 well, if it's hard for them...what tools could we develop? 16:07:47 did you have any specific ideas? 16:08:04 errors codes? 16:08:09 - debuginfofs-type stuff to get better/quicker backtraces? 16:08:40 adamw: there is some stuff developed for bugzilla.gnome.org folks 16:08:42 - a simpler, anonymous crash-server 16:09:06 (where we can collect all the dupes and push to bugzilla when there's something that's traceable/reproduceable) 16:09:11 like if code 495858 is already reported... DUPE! not open anything 16:09:23 iarlyy: error codes are rarely specific enough to rely on them 16:09:26 do you see that happening wwoods? 16:09:29 iarlyy: (which is why we want backtraces in the first place...) 16:09:34 tk009: see what happening? 16:09:35 wwoods: yeah, i have to say i liked that idea 16:09:43 wwoods: the separate crash server idea 16:09:47 plus, BTW, we don't do anything against leaking secret info to the public bugzilla, but that's not that much concern for Fedora 16:10:03 for the record, the model for that would be kerneloops.org, which is SEPARATE from kernel bugzilla 16:10:04 better than errors codes 16:10:05 adamw: that's what I plan to work on as soon as I can get this autoqa stuff rolling nicely 16:10:06 heh 16:10:20 and yes - something like "oops.fedoraproject.org" 16:10:31 there is a little bit of hope, that Firefox & co. would be dumping crashes to MoFo servers, some people are working on it 16:10:35 wwoods: ah, nice. is anyone else interested in working on it, to share the load / protect against roadblocks etc? 16:10:55 and if you start at http://live.gnome.org/Bugsquad/ there is some stuff 16:10:58 adamw: haven't even gotten to that point but I'm sure some of the folks in Brno might be interested 16:11:08 so i see a few things we can do here: 16:11:30 1) talk to abrt people about trying to retrospectively apply their improved dupe detection code to bugzilla (when they have some) 16:11:33 one of the things that would be reeeally useful to that effort is to identify the minimal set of things for a useful, anonymous bug report 16:11:42 http://live.gnome.org/Bugsquad/TriageGuide/FindingDuplicates 16:11:48 2) register that we (bugzappers) consider the current flood of dupes to be a significant problem 16:12:00 3) look at tools such as mcepl has mentioned that other bugzillas use 16:12:17 on 2, would we as a group support the wwoods proposal of a separate crash server? 16:12:24 I was thinking a little bit whether it would be possible to parse the backtrace file and lift to the comment relevant part of the backtrace 16:12:46 i think it would be a sensible way to come at the problem, personally 16:12:53 adamw lead on please? I have to afk 16:12:59 tk009: sure, sorry to overrun 16:13:00 mcepl: I think that would help a lot - seems like it would really help you guys to identify dupes 16:13:44 wwoods: except it is not possible for all backtraces with simple Javascript ... I could e.g. parsing on "signal handler" string , but it is not always there. 16:13:56 but at least sometimes it could help 16:13:59 it might be better to do it abrt-side? 16:14:06 seems like it might be more robust there 16:14:09 maybe 16:14:13 yeah, seems like something you'd want in the bug reports 16:14:46 so...who wants action items here? i'm happy to help with the communication bits or get out of the way, as appropriate 16:14:48 which leads us again to what is already in b.g.o (Why they didn't learnt there more is question Ididn't want to even ask, or I would loose my cool) 16:15:03 I can certainly talk with Brno guys 16:15:39 and i think it'd probably be good for wwoods to talk to jmoskovc too, just to make sure the oops server idea gets off the ground 16:16:01 kimf: greetings - apologies, there was a bit of a screw-up with the meeting time, if you're going off the EST time posted in the announcement 16:16:13 this https://bugzilla.gnome.org/show_bug.cgi?id=602226 looks much more sane IMHO 16:16:14 Bug 602226: critical, Normal, ---, empathy-maint, RESOLVED DUPLICATE, crash in Empathy: dragging conversation ta... 16:16:23 anyway 16:16:27 I think I am done 16:16:34 * wwoods has to run 16:16:43 ok, let me dole out arbitrary action items 16:16:55 #action wwoods to talk to abrt team about working together on the 'oops server' idea 16:17:03 sorry folks, I just to raise the point that abrt should not allow a BZ ticket creation without BT 16:17:12 * wwoods should remember to never leave before the action items are handed out 16:17:17 #action mcepl to talk to abrt guys about improving both automatic dupe detection and assistance for manual dupe detection for abrt-reported bugs 16:17:20 wwoods: =) 16:17:39 hdia: that sounds like a good point, hold on a sec while i do action items :) 16:17:52 oki ;) 16:18:03 #action adamw to report to existing -devel thread that bugzappers considers the dupe flood a problem, and talk to abrt guys about retroactive dupe detection in bugzilla 16:18:09 does the above look good to you guys? 16:18:13 hdia: that's covered, it shouldn't happen with upcoming versions of abrt 16:18:18 adamw: ^^^^ 16:18:19 mcepl: ah great 16:18:21 ;) ... good . 16:18:25 excellent 16:18:31 adamw, very good 16:18:35 mcepl: there's a question for you in -bugzappers btw 16:18:41 a sec 16:19:00 so, anything else to discuss in the meeting? any worries / queries, particularly from newer members? don't be shy :) 16:19:02