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