15:00:18 #startmeeting - BugZappers Meeting 15:00:26 * hello 15:00:29 present 15:00:34 hello arxs 15:00:35 * SMParrish_ here 15:00:37 * adamw raises a limb 15:00:44 and all =) 15:00:54 rjune should be around too? 15:01:02 #chair adamw rjune_wrk 15:01:14 ah, he has a work meeting i think. 15:01:27 he wasn't sure if he could make it 15:02:01 I don't see comphappy 15:02:24 #topic - Triage Metrics - Update on the FAS integration and overall status. 15:03:03 adamw do you know anything about the status 15:03:15 last time I saw he was going to update you last wednesday 15:03:21 not since last meeting, iirc 15:03:29 let me check if we talked and i lost it :) 15:03:32 just a sec 15:03:36 =) 15:03:50 they don't see to be updating 15:03:58 does anyone else notce that? 15:04:30 oh yay :) 15:04:43 right, and if you force to changed the timeframe, some 404 poped-up 15:04:44 comphappy: we're on your topic - can you give us an update on the triage metric system status? 15:05:20 me 15:06:00 sorry 15:06:01 /me 15:06:16 * mcepl has add something to the text. 15:06:34 Got up late last nights version is sitting on laptop 15:07:02 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 or just having connection trouble 15:10:39 maybe we should continue and we can come back later if he returns :) 15:10:42 should we come back to it? 15:10:44 kk 15:10:51 next up 15:11:00 #topic - Kernel Triage - Discuss the feedback from Chuck Ebbert on kernel triage. 15:11:02 hi smooge btw 15:11:27 good morning 15:11:33 alindebe: are you around btw? jlaska said you may be 15:11:35 we kind of already started talking about this in #fedora-bugzappers 15:11:36 yep 15:11:45 i have to run in a minute 15:12:27 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 no problem 15:12:42 yes thank you for coming 15:12:52 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 adamw without rjune_wrk here is there anything yo uwanted to add to the current topic 15:13:16 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 yeah, chuck asked one specific question 15:13:36 which i think is something andy may well be interested in too... 15:13:53 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 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 As does anaconda 15:14:31 so it would be good to have that up for discussion and see what people think 15:14:45 like in the past, add the "triaged" keyword maybe? 15:14:48 How about a triaged keyword or flag 15:15:07 yeah that was my thought too 15:15:16 a flag would be best 15:15:32 eeeh. 15:15:35 it doesn't seem to fit the flag workflow? who would set triaged? and who would set triaged+ ? 15:15:43 that way we dont run over a bug we've already seen 15:15:49 adamw, alindebe: couldn't kernel and anaconda switch to ASSIGNED/ON_DEV system? Just asking ... 15:16:02 mcepl 15:16:03 Doesn't make sense 15:16:08 yum said no to that 15:16:29 we need something that works for everyone 15:16:34 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 i've gotta run now 15:16:40 or as close to everyone as possible 15:16:41 but i'll read the log later 15:16:46 and we can discuss further on list also 15:16:47 be well brother 15:16:48 thanks guys! 15:16:56 adamw: bye 15:16:59 tk009: i think a flag is better thant a keyword, since the keywork is uses to reflect a blocker 15:17:28 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 see: http://fedoraproject.org/wiki/Anaconda/BugReporting 15:18:08 and: http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow 15:18:14 alindebe: how do you know you've a given bug? how do you mark that? 15:18:19 what do you mean? 15:18:22 triaged a given bug* 15:18:24 alindebe: sorry, I don't see from that page anything about NEW, ASSIGNED, etc. states 15:18:31 mcepl: See the second page 15:18:37 oh sorry 15:18:45 * poelcat joins 15:19:00 hello poelcat 15:19:09 hi poelcat 15:19:10 tk009: We don't, really, because it's not easy or obvious or even helpful, in some cases 15:20:11 alindebe: OK, how is your workflow different from the deafult if you would make one huge mass-change ASSIGNED->ON_DEV? 15:20:13 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 alindebe: really, trying to understand 15:20:48 can summarize what we are trying to figure out? 15:20:51 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 s/can/can someone 15:21:14 poelcat: triage of anaconda and kernel bugs 15:21:19 yeah, sure, but we try to minimize changes in Bugzilla, so the terminology is not the best. 15:21:20 Marking it as ASSIGNED when there *isn't* somebody assigned to work on it seems... pointless? 15:21:27 alindebe: take a look at https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow 15:21:30 I've seen it 15:21:43 ASSIGNED to developers generally? Would it make sense? 15:21:58 I know it's stretching the language. 15:21:59 not really. Developers don't pay attention to bugs not given to them 15:22:04 but does it matter that much? 15:22:17 well, and "bug given to them" would be ON_DEV 15:22:24 not that 15:22:35 why? please explain 15:22:43 most of them only pay attention to bugs which actually have their names in the assignee field. 15:22:50 So, marking something as ASSIGNED... why? 15:23:06 it seems like an extraneous ste[p 15:23:08 *step 15:23:11 the ON_DEV state really doesn't make any sense to most developers, AFAICS. 15:23:30 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 (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 pjones: would it be that difficult to explain meaning of two keywords? 15:23:56 mcepl: what is the overall problem we are trying to solve? 15:24:03 mcepl: the difficult part is that having the two keywords doesn't make any sense 15:24:25 how to triage bug for anaconda, kernel 15:24:29 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 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 without using assifned 15:24:53 yet some way to say this was triaged 15:24:54 pjones: beacuse you have two assigned states already ... as I understand it 15:24:55 tk009: why are *we* trying to figure that out if those teams have an established workflow that works for them? 15:25:03 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 poelcat: ok, giving up, whatever; 15:25:20 *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 I just honestly don't see the point 15:25:41 well the kernel guys said they didn't have a workflow 15:25:49 which is how this started 15:25:52 It's an extra step that doesn't add anything, as far as I can tell 15:26:01 other teams have asked that we not assign 15:26:04 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 so whatever 15:26:18 mcepl: We don't use triage, though 15:26:34 or, not in that order 15:26:38 Um so why can the bug not be assigned to the actual person? 15:26:41 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 poelcat: what specifically? 15:26:59 mcepl: that definition of "triaged" seems completely superfluous... 15:27:04 mcepl: Really, triage gets done in the opposite order 15:27:18 mcepl: seriously, if it hasn't been assigned to an individual, it /hasn't been triaged/. 15:27:24 anaconda bugs can be *hard* to triage sometimes, so they go to the right developer who then knows what to ask 15:27:28 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 I think that is what we are working on here 15:27:53 I thought the idea was to get the bug to the person who would fix it 15:28:01 making sure blockers dont go unseen again 15:28:06 if we can help it 15:28:07 poelcat: yeah, some of them weren't. Some of them were legit bugs that just hadn't gotten commented on yet. 15:28:53 but with that many bugs and 9 developers, it was inevitable that some were not going to get handled instantly 15:29:13 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 So the difference is really what is needed for triage rather than the flow itself 15:29:55 Are those 9 peoples jobs defined enough that say ext4 install bug can be assigned to one person 15:30:01 alindebe: so you never need to ask reporter anything, no NEEDINFO before ASSIGNED happens ever? (for example) 15:30:24 comphappy: to some extent, see http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow 15:30:30 (in the ASSIGNED section) 15:30:41 you never got PEBKAC (thinking about it, maybe not) 15:30:42 ? 15:30:51 mcepl: when that happens, it should be in NEW with NEEDINFO set... 15:30:57 mcepl: sometimes it is obvious which things are needed 15:31:12 (and I gave a general list in the workflow) 15:31:18 Then when triageing a bug why can it not be ASSIGNED to one person 15:31:31 comphappy: It can, as long as you're assigning it to a person 15:31:44 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 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 mcepl: but that doesn't make any sense 15:32:04 mcepl: it's in the bloody past tense 15:32:10 sometimes bugs which look like they're x are really y, and the developer will be able to see that 15:32:13 Yes but that is our workfloow 15:32:26 comphappy: not ours 15:32:30 everyone please be calm 15:32:37 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 yes but that workflow makes developers want to throw rocks at you. 15:33:08 mcepl: I don't want to silence you, I really don't. 15:33:19 Pjones: i am a developer and i like ot 15:33:55 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 alindebe: that seems like a fair compliant... seems like we should address those directly as they happen 15:34:33 The idea it to get bugs to the person who will fix it and request NEEDINFO if it is needed 15:34:44 agree poelcat 15:34:49 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 we cant fix what we dont know about 15:34:56 alindebe: otherwise we can scale or grow people helping 15:35:19 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 mcepl: Does having a written workflow for anaconda help? 15:35:31 so I asked alindebe to document our process 15:35:35 which she did 15:35:51 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 alindebe: sure, it does. 15:36:38 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 alindebe: denise do you feel that currently documented process works and has enough people to do it effectively? 15:37:13 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 alindebe: I agree they dhould talk to then but jow does that inyerfear with our work flow 15:38:03 mcepl: Sometimes it is, but half our bugs are hardware-dependent that *we* don't even have the hardware for 15:38:04 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 (okay, I'm exaggerating with half) 15:38:23 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 comphappy: anaconda has never used that workflow 15:38:34 pjones: of course (I cannot properly triage half of the bugs myself) 15:38:54 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 alindebe: Lets not say we don't want to use it because it is not what we do 15:39:20 pjones: and I can imagine not everybody has spare SAN/NAS to test installation over it :) 15:39:25 mcepl: I wouldn't recommend anaconda to a novice triager. It's complex. 15:39:44 comphappy: It's not what we do, and it never has been. Changing would disrupt me, and the developers 15:39:47 mcepl: none of that stuff is something that requires having the hardware, but much of it *does* require some sophistication. 15:40:01 mcepl: and again, testing the setup isn't really what we need triagers for. 15:40:12 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 I'm not disagreeing with that at all. 15:40:36 pjones: well, or other way around, what do you understand trige to be? 15:40:37 some here for triage of NetworkManager 15:40:50 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 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 alindebe: We need to work as a whole project 15:41:34 comphappy: Why? 15:41:36 poelcat: right, anything else on the agenda? 15:41:46 yes one item 15:41:46 comphappy: anaconda has been doing fine not being a part of bugzappers 15:41:49 * poelcat isn't running the meeting :) 15:41:52 which is why I let this go 15:42:05 we all agree we want to help 15:42:12 alindebe: This is fedora 15:42:24 pjones: OK, which is IMHO exactly what we expected ASSIGNED bug should be. 15:42:50 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 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 mcepl: I was asked to? 15:43:03 And I would like help 15:43:08 ok we can continue this on the mail list and in next weeks meeting. 15:43:10 but 15:43:19 you are helping alindebe 15:43:24 jsut being here 15:43:48 I didn't mean to cut you off 15:44:24 please say what yo uwanted to alindebe 15:45:07 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 (and I don't know why ON_DEV exists at all in environment without a dev->staging->production methodology.) 15:45:15 So 15:45:24 we wont jsut jump in 15:45:29 that is why we are talking now 15:45:30 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 to get a handle on anaconda and its bugs 15:46:07 that is a fair request 15:46:13 I'd be more comfortable with, in the future, just going to it 15:46:27 i'm reading it now and i find it workable 15:46:42 *I'm* still wary of assigning bugs without checking first 15:46:45 though i'm not really a sophisticated triager yet 15:47:04 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 From a metrics point of view I can only tayler to one workflow 15:47:18 comphappy: So don't triage anaconda 15:47:37 alindebe: I am not I am talking metrics 15:47:38 clam please 15:47:47 we will work together 15:48:01 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 tk009: I think we are pretty claim *this time* ;-) 15:48:16 I am not sure =P 15:48:32 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 then that is what we will do 15:48:57 no muss no fuss 15:49:01 lovely :) 15:49:28 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 If the correct dev cannot be identified I don't assign it to them in our workflow 15:49:45 alindebe: BTW, sorry my ignorance, is there #fedora-anaconda channel? 15:49:51 mcepl: #anaconda 15:49:55 if you guys have questions, we can hang out on bugzappers and answer 15:49:56 thanks 15:50:09 thank you denise 15:50:18 comphappy: If the correct developer can't be identified, it should be left in NEW 15:50:24 now I will cut everyone off... sorry 15:50:29 tk009: what do you think abot my conclusion? 15:50:32 Yes that is what I do 15:50:33 last item and 10 minutes left 15:51:04 tk009: OK, go ahead 15:51:08 #topic - Component list update for the F12 cycle - Update on status. 15:51:19 this was an action of mine 15:51:34 after talking to jds2001 and f13 15:52:22 they advised using critical components path they were working on as par of FAD 15:52:36 I should have the link but I am slack and don't atm 15:53:15 FAD? 15:53:29 Fedora activity day 15:53:34 oh, I see 15:53:42 the big brains got together 15:53:51 came up with some good stuff 15:55:03 as that is a work in progress I wanted to know how we should go forward with updating our components page 15:56:42 it y fault not having the link but there is little there at the moment anyway 15:56:49 any thoughts 15:56:56 with time running out 15:57:30 *crickets* 15:57:55 other for the mailing list I guess 15:58:14 anyone have anything they want to say before I end the meeting? 15:58:51 okay then see you all in #fedora-bugzappers 15:58:52 i yust wait if the meeting is done and ask on the bugzappers channel :) 15:59:03 I have a major update to the metrics I was playing with last night 15:59:32 I have a meeting tonight but might be up by next morning 15:59:32 we can talk more in the bz channel 15:59:36 Does the anaconda discussion apply to the kernel component as well (topic was kernel...)? 15:59:43 #endmeeting