12:02:54 #startmeeting 12:02:55 Meeting started Tue Sep 30 12:02:54 2014 UTC. The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:02:55 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:03:12 hello all, meeting agenda for today is at https://public.pad.fsfe.org/p/gluster-bug-triage 12:03:20 #topic Roll Call 12:03:35 * kkeithley_ is here 12:03:43 I hope we have more people than last week.... 12:04:10 there are a lot of people on the channel... 12:04:12 Humble, lalatenduM? 12:04:24 indeed... 12:05:07 pranith said he wanted to join too... not sure what happened to that intention 12:05:47 #chair kkeithley_ 12:05:47 Current chairs: kkeithley_ ndevos 12:05:50 hah! 12:05:54 ;-) 12:06:40 pranith was probably busy with the Denali release, along with everyone else. Now that that is over, maybe they just need a reminder 12:06:41 * krishnan_p is here 12:07:25 pk started about this meeting yesterday, he is aware... 12:07:31 #chair krishnan_p 12:07:31 Current chairs: kkeithley_ krishnan_p ndevos 12:08:03 * krishnan_p is wondering what being the chair involves? ;) 12:08:18 krishnan_p: you can now do a #endmeeting :P 12:08:24 but not yet! 12:08:28 * lalatenduM is here 12:08:32 ndevos :) 12:08:33 #chair lalatenduM 12:08:34 Current chairs: kkeithley_ krishnan_p lalatenduM ndevos 12:08:37 ndevos, was talking to Humble :) 12:08:51 lalatenduM: great, but get him to join too! 12:09:01 lalatenduM: and maybe some others in the office? 12:09:03 ndevos, yeah he is joining 12:09:10 well, let's triage some bugs 12:09:21 #topic Bugs in NEW or ASSIGNED state where a non-developer is assigned 12:09:34 I'd like to know more about what we'll do with that ^ 12:09:36 ndevos, I am in 12:09:46 #chair Humble 12:09:46 Current chairs: Humble kkeithley_ krishnan_p lalatenduM ndevos 12:09:48 what's the magic bugzilla search url? 12:10:01 http://goo.gl/JxXzUR is a report that contains the users and NEW/ASSIGNED bugs 12:10:19 thanks 12:10:30 if there are any non-developers, we should move the bugs to NEW and assign them to gluster-bugs@redhat.com 12:10:42 at least, that is my opinion 12:10:52 what do others think about that? 12:11:00 agreed 12:11:25 and #1 on the list is avati. Pretty sure he's not fixing bugs these days. 12:11:37 agreed 12:11:46 right, that is what the problem is 12:12:06 #2 rwheeler? 12:12:13 it also got point out by a community user: https://twitter.com/Supermathie/status/516215217353928704 12:13:26 #info avati and rwheeler should not be assigned to any bugs anyomre 12:13:47 how about bugs in NEW status? 12:14:12 when a developer is supposed to work on it, the bug should be in ASSIGNED, right? 12:14:59 that's what I would presume 12:15:17 ndevos, yes 12:15:32 ndevos, that's my understanding too. 12:15:38 so, should we assign any bugs in NEW to gluster-bugs@redhat.com? 12:16:45 ndevos, nope , it should be assigned to individuals 12:16:57 that's what happens by default. Unless the person who files the bug assigns it to someone? 12:17:02 right? 12:17:06 ndevos, by deafult bugs are assigned to mailling lists 12:17:21 when we triage it should be a 'person' and move to "ASSIGNED" 12:17:47 bugs@gluster.org is notified anyway.. 12:17:49 that is the *current* default, old bugs were assigned to a person when they got filed (NEW -> person assigned) 12:17:53 #info bug report lifecycle http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle 12:18:02 ndevos, thats true.. 12:18:18 lets get that assigned to 'right person' 12:18:33 we've dropped the ball on triaging old bugs, and now we have many bugs in a weird state 12:18:47 Humble: bug who is the 'right person'? 12:18:48 hchiramm, there is one danger associated with it. People may assume that the assignee is working on it while that may not be the case at all. 12:19:03 ndevos, component owner ? 12:19:23 hchiramm, so, IMO the assignee should perform the move to NEW to ASSIGNEE or the assigning of a bug to an individual must be done by the said individual 12:19:39 Humble: component owner is the mailinglist, right? 12:19:58 ndevos, when we triage it can be a person ... 12:20:17 later he can decide and divide that to the team responsible for that component 12:20:30 Humble: yes, it can... but that is actually an other topic on the agenda :) 12:20:35 :( 12:21:43 I hope we can make this two points 12:22:03 1. correct the status of old bugs (assigned to non-developers) 12:22:40 + 12:22:44 2. define a workflow/procedure on how to get a bug assigned to someone (different topic on the agenda) 12:23:27 for (1) the open point is: should we assign bugs in NEW to gluster-bugs@redhat.com ? 12:24:00 ndevos, I think we should assign it to gluster-bugs@redhat.com 12:24:01 alternatively, we could add gluster-bugs@redhat.com and/or bugs@gluster.org to the CC list 12:24:26 anyone else agrees with krishnan_p? 12:24:27 that would allow us to form a bucket of bugs that are not being actively worked upon 12:24:38 krishnan_p: yes, indeed and we can then triage those 12:24:45 ndevos, then later we have to triage again.. 12:24:48 krishnan_p, +1 12:24:56 I see it as duplicate process 12:25:15 Humble, we could add triaged as part of the comment, or some other bugzilla form 12:25:25 there should be way to know which are the bugs being worked upon and which are not 12:25:44 Humble: changing the assignee is easy enough, its two commands (if you have python-bugzilla installed) 12:25:58 ndevos, yep :) 12:26:05 Humble, I am not sure if you saw my question to you previously in this meeting. I had asked you what happens to bugs assigned to me (for eg.), during triaging, that I am not really working on actively. 12:26:14 and triageer make sure that imp bugs should be in the pool which is being worked uppon 12:26:26 krishnan_p, sorry if I missed the question :) 12:26:31 do we know if a bug in NEW+assignee has been triaged? 12:26:50 ndevos, we need a way by which we can mark a bug as triaged, 12:27:00 ndevos, assigned bugs should be the triaged bugs 12:27:05 krishnan_p: we do that with the 'Triaged' keyworr 12:27:09 *keyword 12:27:11 the assignee field could be additionally used to identify bugs that are being actively worked upon 12:27:15 krishnan_p, I was just passing my views.. 12:27:19 :) 12:27:26 if anyone is working on a bug that means it is triaged 12:27:35 as he is working upon it 12:27:38 hchiramm, yeah definitely :) 12:27:43 krishnan_p: I only think the assignee is valid when a bug is in ASSIGNED 12:27:46 should we retain the bug in NEW if not being worked on actively? 12:27:54 lalatenduM: +1 12:27:58 hagarth, IMO yes 12:28:00 hagarth: yes, I think so 12:28:06 hagarth: yes 12:28:10 ok, how about this? 12:28:25 ASSIGNED and gluster-bugs@redhat.com (triaged, not being worked on) 12:28:37 ASSIGNED and (being worked on) 12:28:49 make sense :) 12:28:53 NEW and * (not triaged, not being worked on) 12:28:59 hagarth: we already have, bug triage -> add 'Triaged' keyword -> bug open to be worked on (still in NEW) 12:29:09 ndevos: ah ok, cool! 12:29:53 ndevos, then what is the question that remains for us to answer from looking at bugzilla (in the context of triaging activity)? 12:29:58 I prefer to not move a bug to ASSIGNED, until someone will be able to progress it - ASSIGNED may set some expectations towards the bug reporter 12:30:14 ndevos, +1 12:30:20 ndevos, +1 12:30:43 #agreed Move bugs in NEW+assignee to NEW+gluster-bugs@redhat.com 12:31:13 krishnan_p: the question is what happens after a bug has got the 'Triaged' keyword 12:31:28 ndevos, OK. 12:31:31 #topic What happens after a bug has been marked "Triaged"? 12:32:09 so, once bugs have been triaged, they are in NEW and have the "Triaged" keyword 12:32:16 we can list these bugs pretty easily 12:33:01 * ndevos does not seem to have a bugzilla url for that yet, just a sec.... 12:33:37 Triaged bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&component=glusterd&f1=keywords&list_id=2882276&o1=allwords&product=GlusterFS&query_format=advanced&v1=Triaged 12:33:58 count: 7 12:34:10 untriaged bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&component=glusterd&f1=keywords&list_id=2882269&o1=nowords&product=GlusterFS&v1=Triaged 12:34:13 count: 56 12:34:32 no, that cant be right... 12:34:51 ah, drop the &component=glusterd from the url 12:35:11 untriaged bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=keywords&list_id=2882269&o1=nowords&product=GlusterFS&v1=Triaged 12:35:16 -> 372 12:35:43 triaged bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=keywords&list_id=2882288&o1=allwords&product=GlusterFS&query_format=advanced&v1=Triaged 12:35:50 -> 38 12:36:13 back to the question: What happens after a bug has been marked "Triaged"? 12:36:48 who should be responsible for checking triaged bugs, and get them assigned to be worked upon? 12:36:48 ndevos: respective component owner takes care of it? 12:37:02 ndevos, we encourage developers to pick these bugs and fix it 12:37:23 according to severity and priority 12:37:38 pranithk: +1 12:37:49 pranithk: we can not expect a component owner to take care of all bugs, or can we? 12:38:22 ndevos: should we have a bugzilla steering committee to work with respective owners? 12:38:41 ndevos: why not? there are a lot of people for each module. We can take care of them IMO 12:38:54 hagarth: I do not know if we should - I would prefer lalatenduM's approach 12:39:14 ndevos: yeah.. less process is better... 12:39:31 ndevos: right, ok. 12:40:02 pranithk: well, that means the component owner should have the permissions/ability to assign bugs to developers - and the developers actually work on that 12:40:24 ndevos: At least I have it IMO 12:40:35 hagarth, ndevos if we have enough people fixing these bugs , all committees will work fine else we will be in the same situation as we are 12:40:56 lalatenduM: we need a program manager types to remind people I think 12:41:06 pranithk: that also means that you know who has the knowledge and time to work on those bugs, it is more of a management kind of call 12:41:14 hagarth, yup, I think you are the right person for this :) 12:41:45 lalatenduM: unfortunately, my copious spare time doesn't let me find cycles for this :) 12:42:00 hagarth: yes, something like that, someone who keeps track of developers and also regulary checks on progress of stale/old bugs 12:42:04 hagarth, agree :) 12:42:34 hagarth, who you think would be good to this kind of role? from community pov 12:42:35 JustinClift: ^^ is this your kind of thing? ;) 12:42:39 * ndevos notes that bugzilla has a 'clone' button, but it doesnt work on hagarth 12:43:05 lalatenduM: let me think a bit more about this 12:43:05 :) 12:43:27 ndevos: our team is hungry for fixing bugs ;-) 12:43:37 hagarth: +1. He is already doing it 12:43:52 hagarth: I meant JustinClift 12:43:58 * kkeithley_ thinks if a community bug is a real bug, it probably exists in downstream, and the component owner would usually clone the bug. And that person's manager would be tracking open bugs in downstream and assigning resources to fix them. 12:44:00 pranithk: okay, and how does that team like to find bugs that they can fix? 12:44:02 hagarth, once we hav enough dev interested to fix community bugs , then I think we would be in an awesome state :) 12:44:22 kkeithley_: I think we need to think beyond any downstream product for community glusterfs 12:44:39 s/product/product's processes/ 12:44:59 hagarth: Well, I'm only really keeping track of "high touch" Community issues and important Community Members whose needs I understand 12:45:04 * kkeithley_ further thinks that as the bug gets fixed — upstream first — the bzs get closed. 12:45:18 JustinClift: right 12:45:29 ndevos: We just talk and fix bugs we find... 12:45:39 If I also had to know/track every bug, that sounds like a full time role to me 12:45:47 ndevos: you can have an AI on me for this. I'll try to see if we can find somebody to help with this. 12:46:03 pranithk: how about bugs filed by community members that do not send an email to a mailinglist? 12:46:06 We can also ask for suggetions on the gluster-devel and gluster-users mailing list 12:46:09 hagarth, that's an over simplification, but, e.g., I think it's how RH manages bugs in different parts of the kernel. E.g. ask Ric how he used to manage bugs when he was in charge of the fs team 12:46:41 ndevos: For the past two weeks we only tested it found bugs and sent fixes. Now that I will keep a closer look on bugs to afr We can take care of afr bugs... 12:46:43 There are a group of Community members that have experience with this stuff that may have suggestions 12:46:53 #action hagarth will look for somebody that can act like a bug assigner manager kind of person 12:47:36 pranithk: okay, and for that the bugzilla notifications by email would be sufficient? 12:47:42 kkeithley_: we need to think beyond RH processes for the community. there are several components in GlusterFS that is of interest to the community alone. RH or anybody else having a product on GlusterFS would not care for such components. 12:47:48 ndevos: I believe yes... 12:48:09 pranithk: and, meaning that you and other afr guys will get these bugs assigned and fixed? https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&component=replicate&f1=keywords&list_id=2882288&o1=allwords&product=GlusterFS&query_format=advanced&v1=Triaged 12:48:16 * JustinClift again feels if we have an established outreach program (actively getting ppl involved), this would be easier 12:48:21 And yeah, we all know this. ;) 12:48:23 (and yes, that list is dynamic, more bugs will get triaged) 12:48:25 ndevos: yes sir we will. 12:48:36 JustinClift, +1 12:48:40 hagarth: I don't disagree with that. I'm just suspicious that we sometimes have a disconnect between upstream and downstream bugs and how they get fixed. 12:48:47 pranithk: that sounds good, do you think it would work for other teams too? 12:48:52 where there's overlap 12:49:12 Do the gluster board member's companies have resources they could get involved with this? 12:49:30 ndevos: Not sure. It will work for us IMO 12:49:49 kkeithley_: yes, that disconnect should be tweaked through internal RH processes .. but that's a separate discussion. 12:49:57 pranithk: that would result in a reduced list of URLs with Triaged bugs, and have different teams check that url (or rss feed) regulary 12:50:15 hagarth, I also agree with kkeithley_ at this point of time, I think everybody should the real value in fixing upstream bugs 12:50:24 ndevos: Sure. Will send out a mail in the team mailing list 12:51:39 side question: what's the diff between gluster-bugs@redhat.com and bugs@gluster.org? 12:51:41 lalatenduM: *nod* 12:51:43 ndevos: You can be the bad guy and just assign the bug to specific component and it will somehow find its way because people assign the bug to the respective team ;-) 12:52:15 IOW, does bugs@gluster.org actually go to someone? 12:52:18 pranithk: but how is a bug assigned to a 'team'? how can the community follow that assigning of bugs? 12:52:36 kkeithley_: bugs@gluster.org is supposed to be a replacement for gluster-bugs@redhat.com 12:52:54 kkeithley_: both are mailinglists, gluster-bugs@redhat.com is Red Hat internal and so the community can not really use it 12:53:09 pranithk: maybe we should have these discussions on gluster-devel with afr tag in the subject line or something like that? 12:53:41 hagarth: sure 12:53:42 hagarth: I do not think we should send an email for each bug that got triaged, the list is available in bugzilla 12:53:49 pranithk: noooooo 12:53:57 ndevos: right, but summary should be available on gluster-devel 12:54:06 s/should/could/ 12:54:31 hagarth: why? 12:54:33 ndevos: ? 12:55:20 anyone interested in afr bugs can follow the gluster-bugs@redhat.com bugzilla user, and receive all bugzilla emails 12:55:25 * kkeithley_ was just asking because there are (only) two bugs assigned to bugs@gluster.org and the default assignee on new bugs is gluster-bugs@redhat.com. 12:55:27 ndevos: to answer your question, having bugs@gluster.org in the default CC would work 12:55:47 with filters on the component, you can put all replicate/afr bugs in a specific folder 12:56:03 like explained in http://www.gluster.org/community/documentation/index.php/Bugzilla_Notifications 12:56:03 we would need to get folks move to bugs@gluster.org and nuke gluster-bugs@redhat.com 12:56:07 kkeithley_, unfortunately we cannot directly assign to "bugs@gluster.org" which is a public mailing lists 12:56:21 Humble: can that be changed? 12:56:21 I see 12:56:27 ndevos, no.. 12:56:37 oh... :-/ 12:57:09 is it the default CC yet? 12:57:12 I came to know about it when working with bugzilla team on bug assignment :) 12:57:13 Humble: can we have bugs@gluster.org be in the default CC for all components? 12:57:19 kkeithley_, so yes, its in Cc list 12:57:20 kkeithley_: yes, it seems to be 12:57:32 hagarth, yep it is 12:57:36 ok .. maybe we should advertise this list on gluster mailing lists 12:57:53 Humble: has bugs@gluster.org been added to all open bugs too? 12:58:11 ndevos, thats what the request I put .. 12:58:19 and I feel its working 12:58:34 * ndevos opens a random old bug to check 12:58:42 2 components (website and project-infrastture) have "gluster-infra@gluster.org in Cc list 12:59:03 ndevos, hagarth if its not working I can work with bugzilla team 12:59:36 Humble: ok 12:59:58 those are the same two bugs that are assigned to bugs@gluster.org 13:00:12 * lalatenduM will be brb 13:00:18 Humble: it does not seem to be the case - old bugs do not have bugs@gluster.org on cc 13:00:46 ndevos, the request was closed a month back .. 13:00:50 #action ndevos to add bugs@gluster.org on all existing gluster bugs 13:01:08 Humble: its not an issue, I'll get that done (I'm doing a lot with the bugzilla command ;) 13:01:18 so the bugs opened recently should have it . 13:01:23 ndevos, go ahead :) 13:01:36 Humble: yes, new bugs have it, older bugs do not seem to 13:01:48 that mailing list was not available 13:02:02 it was created by misc recently when we had this requirement 13:02:28 #action pranithk to report next week how his team is assigning triaged bugs 13:02:37 ndevos: yes sir! 13:03:33 meeting time is over - we have addressed two topics now 13:03:47 shall we finish and handle the rest next week? 13:03:53 ndevos: yes 13:04:08 any one else? 13:04:14 no? or yes? 13:04:18 ndevos: maybe we need to move/cancel next week's meeting 13:04:21 ndevos, yes. we can handle the rest next week 13:04:21 ndevos, I doubt abt the next week availability of most of us. 13:04:28 holiday in BLR next week 13:04:31 ah, true 13:04:50 how is meeting on monday? 13:04:50 hagarth: ah! yes. 13:05:20 ndevos, yeah next week is difficult 13:05:27 ndevos: monday is also an off day 13:05:32 ndevos, specially on Monday and Tuesday 13:05:37 hagarth: what holidays next week? I thought they are thursday and friday this week? 13:05:37 oh, okay... 13:05:53 pranithk: will message you later 13:05:59 hagarth: okay 13:06:08 well, lets skip next week then - and we'll meet in two weeks again 13:06:15 pranithk, you need some cooloff time :) 13:06:16 thanks .. Bye .. 13:06:25 ndevos++ 13:06:26 #agreed No meeting next week 13:06:34 ndevos yeah 13:06:37 btw, I fixed all thr bugs assigned to avati and ric 13:06:38 who wants to do the #endmeeting part? 13:06:40 ndevos++ 13:06:45 kkeithley++ 13:06:53 #endmeeting