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