BugZappers/Meetings/Minutes-2009-Jun-23

Bug Triage Meeting :: 2009-06-23

Agenda: https://www.redhat.com/archives/fedora-test-list/2009-June/msg00629.html

Attendees

• tk009 (79)
• alindebe (67)
• mcepl (51)
• adamw (28)
• pjones (18)
• comphappy (18)
• poelcat (13)
• arxs (8)
• denise (7)
• SMParrish_ (2)
• azneita (2)
• smooge (1)
• M_J_G (1)
• mpreston (1)
• rjune_wrk (0)

Meeting Recap

• topic - Triage Metrics - Update on the FAS integration and overall status.

comphappy was not able to attend the meeting, he will try to give an update later today.

• topic - Kernel Triage - Discuss the feedback from Chuck Ebbert on kernel triage.

Chuck asked one specific question in his email: If there might be a different way to indicate a bug's been triaged rather than simply setting it to ASSIGNED? During the meeting on some of the available options were discussed, none were agreed upon. We will continue this in the mailing list. - this topic is also related to anaconda, and with members of the anaconda team present at the meeting we took the opportunity to discuss how we can better assist them.

alindebe provided information on the anaconda team's workflow here: http://fedoraproject.org/wiki/Anaconda/AnacondaBugWorkflow and requested that triagers wanting to help with anaconda learn this work flow and work within it. Also see : http://fedoraproject.org/wiki/Anaconda/BugReporting Also a request that triagers communicate and confirm with the anaconda team on #anaconda before setting anything to assigned. BugZappers will follow these instructions if they triage anaconda bugs.

Thank you alindebe, denise and pjones for attending.

• topic - Component list update for the F12 cycle - Update on status.

This was an action item from last weeks meeting. No discussion during the meeting. After the meeting arxs volunteered to create a draft of a revised components list based on information from Critical_Path_Packages_Proposal

• Action Item - arxs will create a draft of a revised components list and update on progress next week.

IRC Transcript

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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!