15:05:03 #startmeeting BugZappers weekly meeting 15:05:03 Meeting started Tue Jan 5 15:05:03 2010 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:05:03 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:05:07 #chair rjune 15:05:07 Current chairs: adamw rjune 15:05:33 hopefully I have this self employed thing about figured out. 15:05:51 #topic roll call 15:05:55 rjune: hehe :) 15:05:57 so who's here? 15:06:05 * tcpip4000 hey 15:06:05 me 15:06:10 * thomasj still alive, around, and hopefully more time this year 15:06:12 here 15:06:51 alrighty 15:07:03 so since my meeting mail didn't actually make the list yet, here's the agenda list 15:07:08 https://fedoraproject.org/wiki/BugZappers:meeting-agenda-list 15:07:21 we have a bit of a problem in that neither of the people who've proposed agenda items are here :)' 15:07:32 but we can definitely talk about some of the items without them 15:07:41 #topic assignee special cases 15:07:52 so this was suggested by hdia, it's something i've sometimes thought about too 15:08:17 there are some cases where picking an assignee for a bug is not straightforward; it's not just the package maintainer as known by bugzilla 15:08:30 hdia provides https://bugzilla.redhat.com/show_bug.cgi?id=548231#c4 as an example 15:08:31 Bug 548231: medium, low, ---, airlied, ASSIGNED, Radeon 4850 corrupt on resume 15:08:46 he suggests documenting this in the Special column of http://fedoraproject.org/wiki/BugZappers/Components_and_Triagers 15:08:51 any thoughts / comments? 15:09:42 me 15:10:19 go ahead :) 15:10:20 so hdia suggests that it is more visible who is assigned to a bug? 15:10:39 patrickian: no, the point is how to document cases where it's not immediately obvious who you should assign a bug to when triaging it 15:11:07 patrickian: e.g. anaconda bugs or x.org bugs, where bugzilla just assigns them to a catch-all alias but they should be assigned to the correct specific developer as part of triage 15:11:24 ok that would be useful 15:11:33 for many components it's not a problem as bugzilla assigns to the right person anyway, but there are special cases 15:12:26 I am not sure we should document it ... that's a special knowledge which should be accquired by asking me 15:12:50 I mean really, I don't think I would like run-by-triage from people who know nothing about Xorg. 15:13:08 mcepl: sure, but in principle we should document all processes as far as possible 15:13:17 as far as reasonable 15:13:27 keeping things as 'special wisdom' that get passed unreliably from person to person doesn't help anyone 15:14:03 think the solution is simple and useful, and would expose "who are on charge of what" and avoids filling the same question to the ones have the knowledge 15:14:09 i'm not sure the 'special' column is really a great place to do it, however 15:14:13 you need to get special knowledge for any reasonably sized package, because there are many special stuff 15:14:39 well, yes, but the answer is always changing, so I would have to maintain one more weird piece of wiki 15:14:44 in any situation where the exception is simple - 'all bugs should be assigned to this person not that person' - we should just fix that in the component database, not document it as an exception 15:14:59 (e.g., krh left us couple of months ago, so it is ajax now who owns intel, etc.) 15:15:01 in situations where the exception is complex, a small column in a big wiki table isn't the best place to explain it 15:15:35 if anybody wants to maintain it, be my guest 15:15:40 yeah, that's always a challenge in this kind of situation, keeping wikiformation up to date 15:15:54 anyone have a stunningly good idea? :) 15:16:10 or can think of other components in this situation beside anaconda and xorg? 15:16:14 or maybe an email to the list? 15:16:40 adamw: and kernel 15:16:41 tcpip4000: that doesn't keep fresh (no-one starting triage is going to search through five years of mailing list archives) 15:16:47 mcepl: yeah, kernel 15:17:01 besides, I really don't this is the only information I would like xorg bug zappers should have 15:17:18 mcepl: of course not, but this was a topic about bug assignments, not xorg triage documentation 15:17:56 I mean, if you want to triage xorg you still needs to come to me anyway (please, do) 15:18:22 i'd be more comfortable about saying 'come to us', nothing should rely on a single person 15:18:27 that's a single point of failure 15:18:34 there is also me or tech33 who could help out new xorg triagers 15:19:03 If you wish I can update the wiki but have to send me the information 15:19:11 yes, of course 15:19:14 (come to us) 15:19:16 anyway, we're kinda deviating...i think so far we have a sense that simple 'exceptions' should be dealt with elsewhere (i.e. bugzilla assignee database) and complex ones aren't very susceptible to documentation 15:19:18 I am not that special 15:19:40 i.e. we can't think of a great way to document the anaconda/xorg/kernel cases... 15:19:49 unless anyone's had a bright idea :) 15:21:13 maybe we can discuss this further next week...hopefully with hdia around 15:21:32 tcpip4000: no, the issue is not one time update, but to maintain in future 15:21:55 tcpip4000: right, we're worried that just throwing this on a random wiki page will wind up in it quickly becoming stale 15:22:40 #topic stack trace documentation 15:23:09 tech33 points out that http://fedoraproject.org/wiki/StackTraces needs to be updated to the abrt era 15:23:12 i think that makes sense 15:24:02 we can probably keep the manual info but just explain that many crashes will be caught by abrt and explain the abrt report process 15:24:16 does anyone have any points to make on that or want to volunteer to do it? 15:25:05 yeah, anybody volunteers to write down to concise prose blobgs of IRC history I can throw his way? 15:26:11 eh? who? what? :) 15:26:21 let me understand... you have the information but not ordered? 15:26:32 oh I meant, you want stack trace analysis documentation 15:26:40 scrap it 15:27:11 i think the suggestion from tech33 is just to update that page to cope with the fact that abrt will automate a lot of the process for most crashes now 15:27:38 yes 15:28:03 well, if people are happy with the idea but no-one else wants to do it, shall we just ask him to do it himself? :) 15:28:22 maybe better is to create a new one explaining that, and leaving the actual for information 15:28:53 well we have pages about abrt already, we don't need to go into any depth 15:29:04 just add a note that abrt covers most crashes with appropriate links to document abrt use 15:29:44 wouldn't it be more useful if somebody maintained my .json files for particular largely triaged components (I volunteer for xorg and firefox)? 15:30:15 mcepl: huh? for what? sorry, i'm missing you here :) 15:31:48 I wonder what's the value of that stacktrace wiki page in time when we have (and should use) script 15:32:54 oh. i see. well, we can't have a script for every occasion... 15:33:49 we do link to the stack traces instruction page from various other pages 15:33:52 http://fedoraproject.org/wiki/Special:WhatLinksHere/StackTraces 15:34:18 i'm not convinced it would be a good idea to remove the page...though obviously it's much nicer to use abrt or a script if available 15:36:13 agree, that page has helped me to understand the undergoing process, but instead reference from there (as adamw states) the abrt process 15:37:19 ok...well i can take an action item to ask tech33 to make the change 15:37:24 sound good? 15:37:33 +1 15:37:52 (always +1 for whatever where somebody else does the work ;)) 15:37:57 #agreed 15:38:09 ups 15:38:30 #action adamw to ask tech33 to make his proposed change to the stacktraces page 15:38:47 ok, so one more agenda item from tech33 15:38:51 #topic 'How should we handle dupes in excess of 5? (overloading orig. repo.)' 15:39:05 that's the exact text he put in the page - i honestly don't understand exactly what he means by it 15:39:14 'overloading the original report' perhaps? 15:39:20 worried about all the dupe notification comments? 15:40:12 dont't see any problem with that 15:40:31 yeah, i'm not sure it's really a problem 15:40:50 * mcepl too 15:40:56 (meaning I don't see the problem either) 15:40:58 instead helps the reader to understand the environment of the bug ("has been reported many times") 15:41:33 who has problem with https://bugzilla.redhat.com/show_bug.cgi?id=538207 15:41:34 Bug 538207: medium, low, ---, sandmann, NEW, [abrt] crash detected in firefox [@ process_responses] 15:41:41 yeah, i haven't heard any developers complaining about it either 15:42:02 they complain about the existence of so many dupes in the first place, of course, but we're aware of that...i don't see any problem with bugzilla's way of handling when we mark bugs as dupes 15:42:26 well if no-one can see a problem here we'd better table it until tech33 is around, perhaps he can explain better :) 15:42:33 i'll let him know about that too 15:43:13 anything outside of this will require a modification to bugzilla 15:43:33 maybe as the launchpad way of said this: "this bug affects XXX people" 15:43:57 yeah, and we try to avoid patching bugzilla 15:44:02 ok, so 15:44:04 and colapse those comments 15:44:14 #agreed no-one sees any problem with bz handling of dupes 15:44:38 #action adamw to ask tech33 to re-add his duplicate question to the agenda if he can explain the problem in more detail 15:44:45 alright, that's the end of the planned agenda 15:44:48 #topic open floor 15:44:55 anyone have anything for open floor? comments, problems, questions? 15:45:53 maybe the recurrent topic of know who are the active bugzappers 15:46:27 well the triagers & components page should list them 15:46:37 if we had a decent statistics system we'd be able to track who's actually active 15:46:57 i know comphappy was talking with a group of people about implementing it as part of fedora community, at fudcon 15:47:09 http://fedoraproject.org/wiki/BugZappers/Components_and_Triagers, exposes people I've hardly seem bugzapping nowdays 15:47:14 as it is i'm not sure we can do anything beyond the wiki page 15:47:35 yeah it needs manual updating - we approved an update to it at a meeting last month but it hasn't really been changed yet (things get slow around xmas :>) 15:48:01 ok, anything I can do to update that please tell me 15:48:05 we have to be a bit careful about pruning people off, only do it if you're really sure they're inactive 15:48:16 of course 15:48:36 but if you know for sure some of the people on there are inactive - maybe compile a list and send it to test-list, ask if anyone objects to any of those people being taken off the page 15:49:05 ok I'll try to reach them by mail and list 15:49:12 ok excellent 15:49:28 #action tcip4000 to work on updating the triagers list, try to contact apparently inactive triagers 15:49:39 anything else? 15:50:08 adamw is planned some section to explain how to test F13alpha when released? 15:50:35 tcpip4000: we usually do that process through the list 15:51:06 when the alpha is released there'll be a mail on the list explaining the validation testing - up to now it's always just been the install test matrix, but now it'll be a bit more complex as we have non-install tests 15:51:16 that's mostly a QA rather than bugzappers issue, but - keep an eye on the list :) 15:51:46 ok, another lack of information is how to test rawhide 15:52:19 there's a whole rawhide page 15:52:42 Releases/Rawhide? 15:52:57 yes 15:53:07 if you figure there's anything missing from there, please bring it up at a qa meeting! 15:53:10 or on the list 15:53:35 ok, to test the fedora rawhide is good to sign QA group? 15:53:44 or F13alpha 15:54:07 yeah, the qa group covers that kind of more general stuff 15:54:12 BugZappers is specifically for triage 15:54:33 you don't really need to 'join' the qa group, it doesn't need a FAS group or anything - as long as you're signed up to the list and following along with things you're part of QA 15:54:38 see 15:54:39 https://fedoraproject.org/wiki/QA/Join 15:55:14 qa meetings are mondays at 1600 utc 15:55:54 yes, I see there going to be a lot of work for F13 testing 15:56:06 yup 15:56:16 ok, so, any other topics or shall we close up?> 15:57:55 alrighty then! thanks for coming everyone 15:57:59 #endmeeting