15:00:18 <tk009> #startmeeting - BugZappers Meeting
15:00:26 <arxs> * hello
01:45:41 * hello 
15:00:29 <mpreston> present
15:00:34 <tk009> hello arxs
15:00:35 * SMParrish_ here
15:00:37 * adamw raises a limb
15:00:44 <tk009> and all =)
15:00:54 <adamw> rjune should be around too?
15:01:02 <tk009> #chair adamw rjune_wrk
15:01:14 <adamw> ah, he has a work meeting i think.
15:01:27 <tk009> he wasn't sure if he could make it
15:02:01 <tk009> I don't see comphappy
15:02:24 <tk009> #topic - Triage Metrics - Update on the FAS integration and overall status.
15:03:03 <tk009> adamw do you know anything about the status
15:03:15 <tk009> last time I saw he was going to update you last wednesday
15:03:21 <adamw> not since last meeting, iirc
15:03:29 <adamw> let me check if we talked and i lost it :)
15:03:32 <adamw> just a sec
15:03:36 <tk009> =)
15:03:50 <tk009> they don't see to be updating
15:03:58 <tk009> does anyone else notce that?
15:04:30 <adamw> oh yay :)
15:04:43 <arxs> right, and if you force to changed the timeframe, some 404 poped-up
15:04:44 <adamw> comphappy: we're on your topic - can you give us an update on the triage metric system status?
15:05:20 <mcepl> me
15:06:00 <mcepl> sorry
15:06:01 <mcepl> /me
15:06:16 * mcepl has add something to the text.
15:06:34 <comphappy> Got up late last nights version is sitting on laptop
15:07:02 <adamw> comphappy: what was the problem with it not updating any more, again? i remember you explained that to me but i forget the details
15:09:38 * tk009 thinks comphappy might not be fully awake yet
15:10:28 <adamw> or just having connection trouble
15:10:39 <adamw> maybe we should continue and we can come back later if he returns :)
15:10:42 <tk009> should we come back to it?
15:10:44 <tk009> kk
15:10:51 <tk009> next up
15:11:00 <tk009> #topic - Kernel Triage  - Discuss the feedback from Chuck Ebbert on kernel triage.
15:11:02 <adamw> hi smooge btw
15:11:27 <smooge> good morning
15:11:33 <adamw> alindebe: are you around btw? jlaska said you may be
15:11:35 <tk009> we kind of already started talking about this in #fedora-bugzappers
15:11:36 <alindebe> yep
15:11:45 <adamw> i have to run in a minute
15:12:27 <adamw> alindebe (andy lindebergh) is the anaconda triager, we're hoping to try and link her work in a bit more to the bugzappers group - thanks for coming to the meeting, andy
15:12:37 <alindebe> no problem
15:12:42 <tk009> yes thank you for coming
15:12:52 <adamw> and that ties in with this topic too...anaconda and kernel triage. we got an email back from chuck of the kernel team on that question
15:13:12 <tk009> adamw without rjune_wrk here is there anything yo uwanted to add to the current topic
15:13:16 <adamw> which should serve as a good point to start a discussion about a process that both we and the kernel team can be happy with
15:13:25 <adamw> yeah, chuck asked one specific question
15:13:36 <adamw> which i think is something andy may well be interested in too...
15:13:53 <adamw> he was asking if there might be a different way to indicate a bug's been triaged rather than simply setting it to ASSIGNED
15:14:20 <adamw> because kernel team likes to use ASSIGNED in another way...i think this is possibly a legitimate request, as ASSIGNED doesn't really _mean_ triaged, and it's one i've heard from other people too
15:14:30 <alindebe> As does anaconda
15:14:31 <adamw> so it would be good to have that up for discussion and see what people think
15:14:45 <arxs> like in the past, add the "triaged" keyword maybe?
15:14:48 <SMParrish_> How about a triaged keyword or flag
15:15:07 <adamw> yeah that was my thought too
15:15:16 <tk009> a flag would be best
15:15:32 <alindebe> eeeh.
15:15:35 <adamw> it doesn't seem to fit the flag workflow? who would set triaged? and who would set triaged+ ?
15:15:43 <tk009> that way we dont run over a bug we've already seen
15:15:49 <mcepl> adamw, alindebe: couldn't kernel and anaconda switch to ASSIGNED/ON_DEV system? Just asking ...
15:16:02 <tk009> mcepl
15:16:03 <alindebe> Doesn't make sense
15:16:08 <tk009> yum said no to that
15:16:29 <tk009> we need something that works for everyone
15:16:34 <mcepl> alindebe: please explain; really don't want to make it difficult, but it will be difficult for us, so I would love to know
15:16:38 <adamw> i've gotta run now
15:16:40 <tk009> or as close to everyone as possible
15:16:41 <adamw> but i'll read the log later
15:16:46 <adamw> and we can discuss further on list also
15:16:47 <tk009> be well brother
15:16:48 <adamw> thanks guys!
15:16:56 <mcepl> adamw: bye
15:16:59 <arxs> tk009: i think a flag is better thant a keyword, since the keywork is uses to reflect a blocker
15:17:28 <alindebe> mcepl: Quite simply, because it would be a huge change in the way we already do things and would require a big readjustment
15:17:40 <alindebe> see: http://fedoraproject.org/wiki/Anaconda/BugReporting
15:18:08 <alindebe> and: http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow
15:18:14 <tk009> alindebe: how do you know you've a given bug? how do you mark that?
15:18:19 <alindebe> what do you mean?
15:18:22 <tk009> triaged a given bug*
15:18:24 <mcepl> alindebe: sorry, I don't see from that page anything about NEW, ASSIGNED, etc. states
15:18:31 <alindebe> mcepl: See the second page
15:18:37 <mcepl> oh sorry
15:18:45 * poelcat joins
15:19:00 <tk009> hello poelcat
15:19:09 <arxs> hi poelcat
15:19:10 <alindebe> tk009: We don't, really, because it's not easy or obvious or even helpful, in some cases
15:20:11 <mcepl> alindebe: OK, how is your workflow different from the deafult if you would make one huge mass-change ASSIGNED->ON_DEV?
15:20:13 <alindebe> I don't know much about other packages, but anaconda bugs are hard. It's not always clear what log file, if any, is needed, it's not always clear if the developers can reproduce the problem themselves or if they're reliant on the reporter, it's not always clear whether something is user or hardware error
15:20:20 <mcepl> alindebe: really, trying to understand
15:20:48 <poelcat> can summarize what we are trying to figure out?
15:20:51 <alindebe> mcepl: Well, firstly it makes less intuitive sense. I can see ASSIGNED being useful on packages which have one maintainer, because it *is* assigned to a person, but anaconda has 9.
15:20:55 <poelcat> s/can/can someone
15:21:14 <arxs> poelcat: triage of anaconda and kernel bugs
15:21:19 <mcepl> yeah, sure, but we try to minimize changes in Bugzilla, so the terminology is not the best.
15:21:20 <alindebe> Marking it as ASSIGNED when there *isn't* somebody assigned to work on it seems... pointless?
15:21:27 <mcepl> alindebe: take a look at https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
15:21:30 <alindebe> I've seen it
15:21:43 <mcepl> ASSIGNED to developers generally? Would it make sense?
15:21:58 <mcepl> I know it's stretching the language.
15:21:59 <alindebe> not really. Developers don't pay attention to bugs not given to them
15:22:04 <mcepl> but does it matter that much?
15:22:17 <mcepl> well, and "bug given to them" would be ON_DEV
15:22:24 <alindebe> not that
15:22:35 <mcepl> why? please explain
15:22:43 <alindebe> most of them only pay attention to bugs which actually have their names in the assignee field.
15:22:50 <alindebe> So, marking something as ASSIGNED... why?
15:23:06 <alindebe> it seems like an extraneous ste[p
15:23:08 <alindebe> *step
01:45:41 * step 
15:23:11 <pjones> the ON_DEV state really doesn't make any sense to most developers, AFAICS.
15:23:30 <mcepl> alindebe: hehe, just working on upgrade to my greasemonkey script for semi-automatic changing of assignees http://mcepl.fedorapeople.org/tmp/sshot-newDefAssigneeButton.png :)
15:23:40 <pjones> (it only really made any sense in the situation it was introduced for -- web development with a shared "development" server you could push to.)
15:23:47 <mcepl> pjones: would it be that difficult to explain meaning of two keywords?
15:23:56 <poelcat> mcepl: what is the overall problem we are trying to solve?
15:24:03 <pjones> mcepl: the difficult part is that having the two keywords doesn't make any sense
15:24:25 <tk009> how to triage bug for anaconda, kernel
15:24:29 <pjones> mcepl: if it's been assigned, it should be in "assigned".  If it hasn't, it shouldn't be.  Why have two assigned states, the more obvious of which doesn't mean assigned?
15:24:34 <mcepl> to move all components to one workflow, so that we don't have to modify our tools, study materials, etc. for two components (albeit important ones)
15:24:35 <tk009> without using assifned
15:24:53 <tk009> yet some way to say this was triaged
15:24:54 <mcepl> pjones: beacuse you have two assigned states already ... as I understand it
15:24:55 <poelcat> tk009: why are *we* trying to figure that out if those teams have an established workflow that works for them?
15:25:03 <alindebe> Again, I don't know how it works with other components, but with anaconda, people pay attention to bugs assigned directly to them, not to the general bug list.
15:25:18 <mcepl> poelcat: ok, giving up, whatever;
15:25:20 <alindebe> *I* pay attention to the general list to deal with it, and having bugs in both NEW and ASSIGNED to look at...
01:45:41 * I* pay attention to the general list to deal with it, and having bugs in both NEW and ASSIGNED to look at...
15:25:29 <alindebe> I just honestly don't see the point
15:25:41 <tk009> well the kernel guys said they didn't have a workflow
15:25:49 <tk009> which is how this started
15:25:52 <alindebe> It's an extra step that doesn't add anything, as far as I can tell
15:26:01 <tk009> other teams have asked that we not assign
15:26:04 <mcepl> alindebe: well, you would at least know which bugs are triaged, i.e. ready to be assigned to somebody particular; but as I said, I don't want to stop peace negotiations with you folks.
15:26:17 <mcepl> so whatever
15:26:18 <alindebe> mcepl: We don't use triage, though
15:26:34 <alindebe> or, not in that order
15:26:38 <comphappy> Um so why can the bug not be assigned to the actual person?
15:26:41 <poelcat> alindebe: how does it get done?  at the end of F11 there were 200 bugs notting had to go through
15:26:47 * mcepl apparently doesn't understand the point of this talk, so goes back to his shell
15:26:55 <alindebe> poelcat: what specifically?
15:26:59 <pjones> mcepl: that definition of "triaged" seems completely superfluous...
15:27:04 <alindebe> mcepl: Really, triage gets done in the opposite order
15:27:18 <pjones> mcepl: seriously, if it hasn't been assigned to an individual, it /hasn't been triaged/.
15:27:24 <alindebe> anaconda bugs can be *hard* to triage sometimes, so they go to the right developer who then knows what to ask
15:27:28 <poelcat> alindebe: from the outside it appeared that a lot of bugs hadn't been triaged and weren't in a "known" state which is why notting went through them all
15:27:48 <tk009> I think that is what we are working on here
15:27:53 <comphappy> I thought the idea was to get the bug to the person who would fix it
15:28:01 <tk009> making sure blockers dont go unseen again
15:28:06 <tk009> if we can help it
15:28:07 <alindebe> poelcat: yeah, some of them weren't. Some of them were legit bugs that just hadn't gotten commented on yet.
15:28:53 <denise> but with that many bugs and 9 developers, it was  inevitable that some were not going to get handled instantly
15:29:13 <alindebe> mcepl: Y'know, thinking about it, "triage" for anaconda really means, "figuring out who the right assignee is and assigning the bug to them". And along with that goes ASSIGNED
15:29:40 <alindebe> So the difference is really what is needed for triage rather than the flow itself
15:29:55 <comphappy> Are those 9 peoples jobs defined enough that say ext4 install bug can be assigned to one person
15:30:01 <mcepl> alindebe: so you never need to ask reporter anything, no NEEDINFO before ASSIGNED happens ever? (for example)
15:30:24 <alindebe> comphappy: to some extent, see http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow
15:30:30 <alindebe> (in the ASSIGNED section)
15:30:41 <mcepl> you never got PEBKAC (thinking about it, maybe not)
15:30:42 <mcepl> ?
15:30:51 <pjones> mcepl: when that happens, it should be in NEW with NEEDINFO set...
15:30:57 <alindebe> mcepl: sometimes it is obvious which things are needed
15:31:12 <alindebe> (and I gave a general list in the workflow)
15:31:18 <comphappy> Then when triageing a bug why can it not be ASSIGNED to one person
15:31:31 <alindebe> comphappy: It can, as long as you're assigning it to a person
15:31:44 <mcepl> pjones: of course, and that's my point, ASSIGNED means in the default terminology, that all this cleaning up, and repackaging is done, and the bug is ready to be assigned to somebody.
15:31:48 <alindebe> comphappy: Though, really, I recommend NOT just assigning it, but talking to the developer on IRC first
15:31:50 * mcepl just really shut up
15:32:01 <pjones> mcepl: but that doesn't make any sense
15:32:04 <pjones> mcepl: it's in the bloody past tense
15:32:10 <alindebe> sometimes bugs which look like they're x are really y, and the developer will be able to see that
15:32:13 <comphappy> Yes but that is our workfloow
15:32:26 <alindebe> comphappy: not ours
15:32:30 <tk009> everyone please be calm
15:32:37 <poelcat> i think our overall goal here be to make sure we have identified all the important open bugs for the release under devel
15:32:40 <pjones> yes but that workflow makes developers want to throw rocks at you.
15:33:08 <alindebe> mcepl: I don't want to silence you, I really don't.
15:33:19 <comphappy> Pjones: i am a developer and i like ot
15:33:55 <alindebe> mcepl: I think my biggest complaint with the bugzapper workflow is that sometimes people have posted "triaged" in a bug and moved it to ASSIGNED without actually having done any triage
15:34:25 <poelcat> alindebe: that seems like a fair compliant... seems like we should address those directly as they happen
15:34:33 <comphappy> The idea it to get bugs to the person who will fix it and request NEEDINFO if it is needed
15:34:44 <tk009> agree poelcat
15:34:49 <mcepl> pjones: alindebe: well, my problem and I try to discuss with you again and again, is that we have effectively two components (albeit, maybe the biggest ones) which are their own separate univers and where nobody dearts to go, so there is not much help possible. If you like it that way, OK, but I don't know it that's the plan.
15:34:53 <tk009> we cant fix what we dont know about
15:34:56 <poelcat> alindebe: otherwise we can scale or grow people helping
15:35:19 <denise> the anaconda bugs are difficult to triage - there is often additional information to collect, and it is unclear who the correct developer would be.
15:35:21 <alindebe> mcepl: Does having a written workflow for anaconda help?
15:35:31 <denise> so I asked alindebe to document our process
15:35:35 <denise> which she did
15:35:51 <mcepl> alindebe: and about ... of course, everybody screws up sometimes, that's the reason why we urge bug triagers to work with maintainers (or in cases of our two, with current bug triagers) to learn the folkways there.
15:36:01 <mcepl> alindebe: sure, it does.
15:36:38 <alindebe> I would be totally okay with somebody looking at a bug, saying "okay, this is partitioning, which requires storage.log and should go to dlehman". But very often, it's not clear if that's *actually* the bug, which is why I recommend pinging the developer on IRC and checking with them first.
15:36:41 <poelcat> alindebe: denise do you feel that currently documented process works and has enough people to do it effectively?
15:37:13 <mcepl> and of course, there is always the question, how much could volunteer bug triager help ... e.g., for Xorg bugs there is always the problem that not everybody has all those graphics cards available. Maybe anaconda is not good component for volunteer bug triagers at all?
15:37:38 <comphappy> alindebe: I agree they dhould talk to then but jow does that inyerfear with our work flow
15:38:03 <alindebe> mcepl: Sometimes it is, but half our bugs are hardware-dependent that *we* don't even have the hardware for
15:38:04 <pjones> mcepl: there are still things a *knowledgeable* volunteer triager can do with your Xorg example, and I would expect that having the hardware isn't really something a triager would ever need.
15:38:16 <alindebe> (okay, I'm exaggerating with half)
15:38:23 <denise> poelcat, I'd love to have bug-zappers helping alindebe if they are ok with the anaconda process, but if not, it will be an additional burden for the developers and we cant afford that
15:38:25 <alindebe> comphappy: anaconda has never used that workflow
15:38:34 <mcepl> pjones: of course (I cannot properly triage half of the bugs myself)
15:38:54 <pjones> mcepl: really, a triager there would need to be checking for things like: having information about package versions, having adequate information about the hardware, having adequate information about config files and such, ...
15:39:15 <comphappy> alindebe: Lets not say we don't want to use it because it is not what we do
15:39:20 <mcepl> pjones: and I can imagine not everybody has spare SAN/NAS to test installation over it :)
15:39:25 <alindebe> mcepl: I wouldn't recommend anaconda to a novice triager. It's complex.
15:39:44 <alindebe> comphappy: It's not what we do, and it never has been. Changing would disrupt me, and the developers
15:39:47 <pjones> mcepl: none of that stuff is something that requires having the hardware, but much of it *does* require some sophistication.
15:40:01 <pjones> mcepl: and again, testing the setup isn't really what we need triagers for.
15:40:12 <mcepl> well, I tell you a secret, good triaging of any component is complex; it took me good year to get at least some understanding what to do about Xorg bugs and quite often I still feel like a newbie.
15:40:34 <pjones> I'm not disagreeing with that at all.
15:40:36 <mcepl> pjones: well, or other way around, what do you understand trige to be?
15:40:37 <arxs> some here for triage of NetworkManager
15:40:50 <denise> yes, thats why we asked alindebe to do a brain-dump on anaconda
15:41:20 * poelcat notes we have 19 minutes left... what do we hope to resolve by the end of the meeting?
15:41:25 <pjones> mcepl: making sure that there's adequate information in the bug that it can be reasonably worked on by a developer, and making sure it's assigned to that developer.
15:41:28 <comphappy> alindebe: We need to work as a whole project
15:41:34 <alindebe> comphappy: Why?
15:41:36 <mcepl> poelcat: right, anything else on the agenda?
15:41:46 <tk009> yes one item
15:41:46 <alindebe> comphappy: anaconda has been doing fine not being a part of bugzappers
15:41:49 * poelcat isn't running the meeting :)
15:41:52 <tk009> which is why I let this go
15:42:05 <tk009> we all agree we want to help
15:42:12 <comphappy> alindebe: This is fedora
15:42:24 <mcepl> pjones: OK, which is IMHO exactly what we expected ASSIGNED bug should be.
15:42:50 <pjones> mcepl: sure, except that's not what you were saying earlier -- I want ASSIGNED to actually have a developer's name on it.
15:42:52 <mcepl> alindebe: of course, and if you want to stay it that way, I have no problem with that. But why then we are tlaking here?
15:43:00 <alindebe> mcepl: I was asked to?
15:43:03 <alindebe> And I would like help
15:43:08 <tk009> ok we can continue this on the mail list and in next weeks meeting.
15:43:10 <alindebe> but
15:43:19 <tk009> you are helping alindebe
15:43:24 <tk009> jsut being here
15:43:48 <tk009> I didn't mean to cut you off
15:44:24 <tk009> please say what yo uwanted to alindebe
15:45:07 <alindebe> Just that, I would love having help. But I'm worried that people just jumping in without understanding how weird anaconda and its bugs can really be would be chaotic at best.
15:45:14 <pjones> (and I don't know why ON_DEV exists at all in environment without a dev->staging->production methodology.)
15:45:15 <alindebe> So
15:45:24 <tk009> we wont jsut jump in
15:45:29 <tk009> that is why we are talking now
15:45:30 <alindebe> if people would be willing to read the anaconda workflow, check out bugs, figure out what *they* think is going on, and then talk to the developer
15:45:45 <alindebe> to get a handle on anaconda and its bugs
15:46:07 <tk009> that is a fair request
15:46:13 <alindebe> I'd be more comfortable with, in the future, just going to it
15:46:27 <azneita> i'm reading it now and i find it workable
15:46:42 <alindebe> *I'm* still wary of assigning bugs without checking first
01:45:41 * I'm* still wary of assigning bugs without checking first
15:46:45 <azneita> though i'm not really a sophisticated triager yet
15:47:04 <mcepl> that is, but if you want to attract as many quality bug triagers as possible, then you probably have to lower the bar as much as possible, but that's really getting off topic here.
15:47:07 <comphappy> From a metrics point of view I can only tayler to one workflow
15:47:18 <alindebe> comphappy: So don't triage anaconda
15:47:37 <comphappy> alindebe: I am not I am talking metrics
15:47:38 <tk009> clam please
15:47:47 <tk009> we will work together
15:48:01 <alindebe> If people can get to the point where they can see a bug, correctly identify the problem, ask for the right info and assign to the right developer, I'm fine with that
15:48:07 <mcepl> tk009: I think we are pretty claim *this time* ;-)
15:48:16 <tk009> I am not sure =P
15:48:32 <alindebe> but while adjusting, I'd really, really prefer if they checked on IRC with the person before sending them bugs that don't belong
15:48:47 <tk009> then that is what we will do
15:48:57 <tk009> no muss no fuss
15:49:01 <alindebe> lovely :)
15:49:28 <mcepl> OK, so let's make conclusion that we will try to attract as many anaconda volunteers as possible but we will warn them sterly, that they have to learn before committing to the component and talk with developers.
15:49:35 <comphappy> If the correct dev cannot be identified I don't assign it to them in our workflow
15:49:45 <mcepl> alindebe: BTW, sorry my ignorance, is there #fedora-anaconda channel?
15:49:51 <alindebe> mcepl: #anaconda
15:49:55 <denise> if you guys have questions, we can hang out on bugzappers and answer
15:49:56 <mcepl> thanks
15:50:09 <tk009> thank you denise
15:50:18 <alindebe> comphappy: If the correct developer can't be identified, it should be left in NEW
15:50:24 <tk009> now I will cut everyone off... sorry
15:50:29 <mcepl> tk009: what do you think abot my conclusion?
15:50:32 <comphappy> Yes that is what I do
15:50:33 <tk009> last item and 10 minutes left
15:51:04 <mcepl> tk009: OK, go ahead
15:51:08 <tk009> #topic - Component list update for the F12 cycle - Update on status.
15:51:19 <tk009> this was an action of mine
15:51:34 <tk009> after talking to jds2001 and f13
15:52:22 <tk009> they advised using  critical components path they were working on as par of FAD
15:52:36 <tk009> I should have the link but I am slack and don't atm
15:53:15 <mcepl> FAD?
15:53:29 <tk009> Fedora activity day
15:53:34 <mcepl> oh, I see
15:53:42 <tk009> the big brains got together
15:53:51 <tk009> came up with some good stuff
15:55:03 <tk009> as that is a work in progress I wanted to know how we should go forward with updating our components page
15:56:42 <tk009> it y fault not having the link but there is little there at the moment anyway
15:56:49 <tk009> any thoughts
15:56:56 <tk009> with time running out
15:57:30 <tk009> *crickets*
01:45:41 * crickets* 
15:57:55 <tk009> other for the mailing list I guess
15:58:14 <tk009> anyone have anything they want to say before I end the meeting?
15:58:51 <tk009> okay then see you all in #fedora-bugzappers
15:58:52 <arxs> i yust wait if the meeting is done and ask on the bugzappers channel :)
15:59:03 <comphappy> I have a major update to the metrics I was playing with last night
15:59:32 <comphappy> I have a meeting tonight but might be up by next morning
15:59:32 <tk009> we can talk more in the bz channel
15:59:36 <M_J_G> Does the anaconda discussion apply to the kernel component as well (topic was kernel...)?
15:59:43 <tk009> #endmeeting