From Fedora Project Wiki
(created meeting minutes)
 
m (internal link cleaning)
 
Line 41: Line 41:


* topic - Component list update for the F12 cycle - Update on status.
* 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 https://fedoraproject.org/wiki/Critical_Path_Packages_Proposal
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.
* Action Item - arxs will create a draft of a revised components list and update on progress next week.
Line 437: Line 437:
|- id="t15:21:27"
|- id="t15:21:27"
! style="background-color: #488888" | mcepl
! style="background-color: #488888" | mcepl
| style="color: #488888" | alindebe: take a look at https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
| style="color: #488888" | alindebe: take a look at [[BugZappers/BugStatusWorkFlow]]
|| [[#t15:21:27|15:21]]  
|| [[#t15:21:27|15:21]]  
|- id="t15:21:30"
|- id="t15:21:30"

Latest revision as of 07:55, 18 September 2016

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!