13:01:57 #startmeeting Weekly Gluster Bug Triage 13:01:57 Meeting started Tue Nov 3 13:01:57 2015 UTC. The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:57 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:09 #info Todays agenda: https://public.pad.fsfe.org/p/gluster-bug-triage 13:02:14 #topic Roll Call 13:02:34 Attendees, please raise your hands 13:03:28 .... okay, not all at once? 13:03:29 * Manikandan is here 13:03:33 * kkeithley_ is here 13:04:25 rastar, skoduri, rafi, jiffin - any of you there? 13:04:38 * rafi is here 13:04:45 ndevos: yes 13:04:48 * skoduri is here 13:05:34 #topic Action Items from last week 13:05:39 #topic pranithk will send a reminder on how to find and fix bugs, attract new contributors 13:05:51 anyone knows if Pranith sent an email? 13:05:52 * jiffin is here 13:06:12 ndevos: I'm not sure 13:06:25 ndevos: I will check with him 13:06:43 me too , i didn't see any mail 13:06:59 #action rafi will check with Pranith about sending a "how to find and fix bugs" email 13:07:25 #topic ndevos to add a agenda for gluster-meeting to discuss about cleaning up of older (which we are not supporting )version tag and bugs from bugzilla 13:07:53 hm, no idea if I ever did that, it's been a few weeks since I last could join a meeting 13:08:18 kkeithley_: I think you did some bug closing, maybe you know more about the status of this? 13:08:44 I started 13:09:03 pre-release as a version is closed for new bugs 13:09:24 I'm thinking about how to handle most of the bugs filed against mainline version 13:09:35 many are RFEs, they should probably remain 13:09:38 okay, good, and what about end-of-life versions? 13:10:05 all the BZs against EOL versions have been closed with a note to reopen on a current version 13:10:13 and the EOL versions have been deleted from bugzilla 13:10:16 yes, Naga sent an email about closing mainline bugs earlier, but he did not respond to my questions :-/ 13:11:20 #link http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12760/focus=12801 13:11:47 do we want to discuss this now, or shall we see if we can get a response from Naga about it? 13:12:35 should we ask a followup on this mail first 13:13:09 yeah, I guess that would be good, and get Naga and others that are interested join this meeting next week 13:13:19 ndevos: was there any discussion about closing mainline bugs in any of the community meeting 13:13:38 * atinm is here for sometime 13:13:38 rafi: I dont know, I was missing in action the last few weeks 13:13:40 ndevos: i rember there was a discussion to close EOL bugs 13:14:05 rafi: can you talk to Naga and ask him to reply to that email, and maybe join next weeks meeting? 13:14:27 * rafi scared to talk with mangers :D 13:14:35 there was some a couple weeks ago, not recently though. Hence me looking at doing something with 1000+ bzs filed against mainline and pre-release 13:14:42 rafi: heh, I can send more emails if you like :) 13:14:55 or atinm might want to ask Naga to follow-up? 13:15:26 ndevos, ok, I will have a word with him 13:15:33 kkeithley_: yeah, we can close mainline bugs when patches get merged, but it'll need some more discussion 13:15:37 atinm: thanks! 13:15:56 #action atinm will try to get a followup from Naga on http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12760/focus=12801 13:16:34 I kinda think we should close all non-RFE mainline bugs when a 3.X.0 release is made 13:16:55 Or change them to 3.X.0 version 13:17:09 we shouldn't have 1000+ bugs open against mainline 13:17:18 kkeithley_, true 13:17:26 kkeithley_, +1 13:17:30 kkeithley_: +2 13:17:32 kkeithley_: I dont have an issue with all those open bugs, they get closed when the next major release (3.8) is done 13:17:46 but they don't. That's part of the problem 13:17:57 I can't digest 1000+ bugs 13:18:30 find me a bug against mainline that has its patches merged in the release-3.7 branch, I dare you :D 13:18:33 some of the bugs filed against mainline are 3+ years old 13:18:42 kkeithley_: wouldn't ndevos's script clean that up in 3.8? 13:18:54 rather once when 3.8 is released? 13:18:59 dunno. I don't know what ndevos' script does 13:19:12 oh, well, bugs that do not have patches at all, and are in NEW will need some edicated guesses to be closed 13:19:27 that's what I'm talking about. 13:19:57 i see 13:20:06 kkeithley_: I have a script that checks the status of bugs, patches in gerrit and merged patches in git - at least bugs with patches should be in a relatively sane state 13:20:40 ndevos, agree..not all issues may get fixed when 3.X.0 gets released 13:20:55 all of the bugs in NEW without patches need some form of triaging, but with the few people that join this meeting, we can't do that 13:21:28 we need to figure out if those NEW bugs are duplicates, or have been fixed in newer releases 13:22:10 * rafi1 lost connection 13:22:17 mass closing them might not be the right approach - maybe update with a note and ask for re-testing with a recent version? 13:22:21 if mainline/master is where on-going devel is happening, it almost feels wrong to file bugs against it. 13:23:03 And if a bug is filed against mainline, it should be reset against the 3.X.0 release once that release happens. IM(H)O 13:23:15 kkeithley_, so do you suggest we file bugs against 3.X and then clone them to mainline while submitting a patch ? 13:23:18 s/against/to/ 13:23:50 skoduri: depends 13:24:03 yes, I agree with the resetting of mainline -> $version when a new major release branch is made - except for bugs with the FutureFeature keyword 13:24:04 if the bug exists in 3.7.x, then yes. 13:24:36 okay 13:24:51 users would mostly file bugs against the release they use anyway, but developers may run the master branch and report bugs against that 13:24:58 ndevos: exactly. FutureFeature, there's also an RFE keyword, or anything that has RFE in the topic/subject. Not everyone is consistent in setting keywords 13:25:19 yes, yes, and yes 13:25:39 keywords in subjects do not mean anything, it is the FutureFeature keyword that we rely on 13:26:04 fine. Get everyone to follow the rules. (herding cats) 13:26:13 we can easily select/search bugs by keyworks, searching partial subjects is a pain 13:26:27 yes, I know. ;-) 13:26:29 well, we have the keywords we use documented :) 13:27:00 :) .. how about we delegate it to component maintainers (+volunteers) to look at respective bugs every week 13:27:32 ndevos, where do we have it documented? 13:27:57 #link http://gluster.readthedocs.org/en/latest/Workflow-Guide/Bug-Triage see the "Keywords" chapter 13:28:15 ndevos++, (y) 13:28:35 skoduri: that is the general plan for this meeting, bit convicing maintainers to join isnt that simle :-/ 13:28:42 *but 13:29:35 anyway, we need to think more about reducing the bugs in NEW state 13:30:07 #action kkeithley_ will come up with a proposal to reduce the number of bugs against "mainline" in NEW state 13:30:35 ndevos, right..what if we ask the maintainers to take a look at (/close) them at their free time (ofcourse with some assistance from volunteers) 13:30:38 I think looking at bugs every week is quite possible for anyone in the team and not necessarily maintainer alone should have a look at.. 13:30:47 in this meeting we can have a check on the bugs remaining and send 13:30:53 reminder mails to them 13:30:57 ? 13:31:23 having one or two to cleanup all those bugs doesn't seem fair :) 13:31:28 skoduri: they do not really need free time, I think it is one of the duties of the maintainers to keep bugs against their components in order 13:32:06 ndevos, so should we remind them about it again? 13:32:10 but yes, it is not something maintainers should be required to do, they tend to be busy and can use assistance from volunteers for that 13:32:30 ndevos, true 13:32:53 ndevos, right..and as we can see not all are available at this time to do group triage together..so maybe we can split this meeting component wise 13:32:56 ndevos: do need to keep for those volunteers 13:32:58 skoduri: I'm trying to convince engineers to help out, there was a recent email to our Red Hat sponsored contributors ;-) 13:33:02 and let maintainers co-ordinate 13:33:40 skoduri: with the number of people joining this meeting at the moment, there is no need to split it up, unfortunately 13:34:19 but triaging is not a "during this meeting only" activity, people can do that anytime, the sooner after a bug gets filed the better 13:34:32 ndevos: +1 13:34:52 ndevos: I would ideally like bugs to be triaged within 24-48 hours of logging a bug 13:34:53 #info triaging is not a "during this meeting only" activity, people can do that anytime, the sooner after a bug gets filed the better 13:35:01 hagarth: yes, me too 13:35:17 this meeting is only a fall-back for untriaged bugs 13:36:11 ndevos: agree, we could then use this as a forum also for interested community members to let us know about problems/bugs bothering them 13:36:21 ndevos: most of the bugs which are cloned from downstream does not seems to triaged 13:36:44 hagarth: yes, that is the idea, and bugs that were difficult to triage can be discussed too 13:37:04 we need to up the level of user participation in this meeting 13:37:17 jiffin: yes, and that is worrysome, engineers do not seem to triage the bugs that they file 13:37:47 ndevos, agree :) ... maybe the way code-reviews are ordered , we should some how make bug-triaging also part of daily activity ...how about auto-assigning a member for each sub-component..and that person is responsible to delegate or assign it to one of volunteers willing to work in that area? 13:38:04 hagarth: I'm trying! you might want to reply to my email about community participation on our internal Red Hat list :) 13:39:04 the same way sometimes they involve any of the co-team members to do the code-review..that way even maintainers shall not be burdened much 13:39:08 skoduri: maintainers/teams working on a component should watch the bugs@gluster.org bugzilla account or subscribe to that mailinglist and filter on their component 13:39:11 ndevos: yes, I intend responding there :) 13:39:25 hagarth: In my opinion , today bug triage meeting peaked with its users 13:39:57 skoduri: would you be willing to help documenting the steps needed to receive bug notifications for a specific component? 13:40:04 ndevos, but that doesn't happen and hence asking why not enforce it? 13:40:32 ndevos, sure..I shall try ..but ofcourse with your help :) 13:40:37 jiffin: we need higher peaks, don't we? this looks like a local maxima to me :) 13:40:44 skoduri: because I prefer an opt-in mechanism that works for non Red Hat contributors too :) 13:41:30 #action skoduri and ndevos will document how people can get bug notifications for specific components 13:41:30 even now we can involve non Red Hat contributors...we just need to know who are interested in :) 13:41:52 but yeah I think we should move to group traige ;) 13:42:13 we need to make it easier for contributors to opt-in, and providing one way for everyone should help with improving that :) 13:42:51 yeah, still 18 minutes left for the triage itself, lets start that 13:43:07 #topic Group Triage 13:43:30 #info 18 bugs have been untriaged and need to be handled in this meeting 13:43:33 #link https://public.pad.fsfe.org/p/gluster-bugs-to-triage 13:43:52 when you triage a bug, put your name in front of the bug 13:44:21 once done, mark the bug as triaged by -s-t-r-i-k-i-n-g- -i-t- -t-h-r-o-u-g-h- 13:49:13 ndevos++ 13:49:55 wohoo! 13:50:49 ndevos, in the list of triage bugs, 1276839 has patch posted already.. 13:51:02 Only the status of the BZ is not changed 13:51:32 Manikandan, it should also have keyword "Triaged" 13:51:41 so you can set the state to POST (and keyword Triaged) 13:51:58 skoduri, kkeithley_ okay 13:52:53 kkeithley_, done :-) 14:00:16 looks like we're almost done, great! 14:01:17 nobody else posted any "open floor" topics, and we're running out of time for todays meeting too 14:01:49 so, thank you all for your participation, and we'll repeat the exercise next week again 14:02:06 next week will be the regular time, 12:00 UTC :) 14:02:20 #endmeeting