13:01:57 <ndevos> #startmeeting Weekly Gluster Bug Triage
13:01:57 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:09 <ndevos> #info Todays agenda: https://public.pad.fsfe.org/p/gluster-bug-triage
13:02:14 <ndevos> #topic Roll Call
13:02:34 <ndevos> Attendees, please raise your hands
13:03:28 <ndevos> .... okay, not all at once?
13:03:29 * Manikandan is here
13:03:33 * kkeithley_ is here
13:04:25 <ndevos> rastar, skoduri, rafi, jiffin - any of you there?
13:04:38 * rafi is here
13:04:45 <rafi> ndevos: yes
13:04:48 * skoduri is here
13:05:34 <ndevos> #topic Action Items from last week
13:05:39 <ndevos> #topic pranithk will send a reminder on how to find and fix bugs, attract new contributors
13:05:51 <ndevos> anyone knows if Pranith sent an email?
13:05:52 * jiffin is here
13:06:12 <rafi> ndevos: I'm not sure
13:06:25 <rafi> ndevos: I will check with him
13:06:43 <jiffin> me too , i didn't  see any mail
13:06:59 <ndevos> #action rafi will check with Pranith about sending a "how to find and fix bugs" email
13:07:25 <ndevos> #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 <ndevos> hm, no idea if I ever did that, it's been a few weeks since I last could join a meeting
13:08:18 <ndevos> kkeithley_: I think you did some bug closing, maybe you know more about the status of this?
13:08:44 <kkeithley_> I started
13:09:03 <kkeithley_> pre-release as a version is closed for new bugs
13:09:24 <kkeithley_> I'm thinking about how to handle most of the bugs filed against mainline version
13:09:35 <kkeithley_> many are RFEs, they should probably remain
13:09:38 <ndevos> okay, good, and what about end-of-life versions?
13:10:05 <kkeithley_> all the BZs against EOL versions have been closed with a note to reopen on a current version
13:10:13 <kkeithley_> and the EOL versions have been deleted from bugzilla
13:10:16 <ndevos> yes, Naga sent an email about closing mainline bugs earlier, but he did not respond to my questions :-/
13:11:20 <ndevos> #link http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12760/focus=12801
13:11:47 <ndevos> do we want to discuss this now, or shall we see if we can get a response from Naga about it?
13:12:35 <rafi> should we ask a followup on this mail first
13:13:09 <ndevos> yeah, I guess that would be good, and get Naga and others that are interested join this meeting next week
13:13:19 <rafi> 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 <ndevos> rafi: I dont know, I was missing in action the last few weeks
13:13:40 <rafi> ndevos: i rember there was a discussion to close EOL bugs
13:14:05 <ndevos> 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 <kkeithley_> 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 <ndevos> rafi: heh, I can send more emails if you like :)
13:14:55 <ndevos> or atinm might want to ask Naga to follow-up?
13:15:26 <atinm> ndevos, ok, I will have a word with him
13:15:33 <ndevos> kkeithley_: yeah, we can close mainline bugs when patches get merged, but it'll need some more discussion
13:15:37 <ndevos> atinm: thanks!
13:15:56 <ndevos> #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 <kkeithley_> I kinda think we should close all non-RFE mainline bugs when a 3.X.0 release is made
13:16:55 <kkeithley_> Or change them to 3.X.0 version
13:17:09 <kkeithley_> we shouldn't have 1000+ bugs open against mainline
13:17:18 <atinm> kkeithley_, true
13:17:26 <atinm> kkeithley_, +1
13:17:30 <jiffin> kkeithley_: +2
13:17:32 <ndevos> 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 <kkeithley_> but they don't. That's part of the problem
13:17:57 <kkeithley_> I can't digest 1000+ bugs
13:18:30 <ndevos> find me a bug against mainline that has its patches merged in the release-3.7 branch, I dare you :D
13:18:33 <kkeithley_> some of the bugs filed against mainline are 3+ years old
13:18:42 <hagarth> kkeithley_: wouldn't ndevos's script clean that up in 3.8?
13:18:54 <hagarth> rather once when 3.8 is released?
13:18:59 <kkeithley_> dunno. I don't know what ndevos' script does
13:19:12 <ndevos> 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 <kkeithley_> that's what I'm talking about.
13:19:57 <hagarth> i see
13:20:06 <ndevos> 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 <skoduri> ndevos, agree..not all issues may get fixed when 3.X.0 gets released
13:20:55 <ndevos> 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 <ndevos> 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 <ndevos> 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 <kkeithley_> if mainline/master is where on-going devel is happening, it almost feels wrong to file bugs against it.
13:23:03 <kkeithley_> 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 <skoduri> kkeithley_, so do you suggest we file bugs against 3.X and then clone them to mainline while submitting a patch ?
13:23:18 <kkeithley_> s/against/to/
13:23:50 <kkeithley_> skoduri: depends
13:24:03 <ndevos> 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 <kkeithley_> if the bug exists in 3.7.x, then yes.
13:24:36 <skoduri> okay
13:24:51 <ndevos> 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 <kkeithley_> 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 <kkeithley_> yes, yes, and yes
13:25:39 <ndevos> keywords in subjects do not mean anything, it is the FutureFeature keyword that we rely on
13:26:04 <kkeithley_> fine. Get everyone to follow the rules. (herding cats)
13:26:13 <ndevos> we can easily select/search bugs by keyworks, searching partial subjects is a pain
13:26:27 <kkeithley_> yes, I know. ;-)
13:26:29 <ndevos> well, we have the keywords we use documented :)
13:27:00 <skoduri> :) .. how about we delegate it to component maintainers (+volunteers) to look at respective bugs every week
13:27:32 <Manikandan> ndevos, where do we have it documented?
13:27:57 <ndevos> #link http://gluster.readthedocs.org/en/latest/Workflow-Guide/Bug-Triage see the "Keywords" chapter
13:28:15 <Manikandan> ndevos++, (y)
13:28:35 <ndevos> skoduri: that is the general plan for this meeting, bit convicing maintainers to join isnt that simle :-/
13:28:42 <ndevos> *but
13:29:35 <ndevos> anyway, we need to think more about reducing the bugs in NEW state
13:30:07 <ndevos> #action kkeithley_ will come up with a proposal to reduce the number of bugs against "mainline" in NEW state
13:30:35 <skoduri> 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 <Manikandan> 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 <skoduri> in this meeting we can have a check on the bugs remaining and send
13:30:53 <skoduri> reminder mails to them
13:30:57 <skoduri> ?
13:31:23 <skoduri> having one or two to cleanup all those bugs doesn't seem fair :)
13:31:28 <ndevos> 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 <skoduri> ndevos, so should we remind them about it again?
13:32:10 <ndevos> 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 <Manikandan> ndevos, true
13:32:53 <skoduri> 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 <jiffin> ndevos: do need to keep for those volunteers
13:32:58 <ndevos> skoduri: I'm trying to convince engineers to help out, there was a recent email to our Red Hat sponsored contributors ;-)
13:33:02 <skoduri> and let maintainers co-ordinate
13:33:40 <ndevos> skoduri: with the number of people joining this meeting at the moment, there is no need to split it up, unfortunately
13:34:19 <ndevos> 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 <hagarth> ndevos: +1
13:34:52 <hagarth> ndevos: I would ideally like bugs to be triaged within 24-48 hours of logging a bug
13:34:53 <ndevos> #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 <ndevos> hagarth: yes, me too
13:35:17 <ndevos> this meeting is only a fall-back for untriaged bugs
13:36:11 <hagarth> 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 <jiffin> ndevos: most of the bugs which are cloned from downstream does not seems to triaged
13:36:44 <ndevos> hagarth: yes, that is the idea, and bugs that were difficult to triage can be discussed too
13:37:04 <hagarth> we need to up the level of user participation in this meeting
13:37:17 <ndevos> jiffin: yes, and that is worrysome, engineers do not seem to triage the bugs that they file
13:37:47 <skoduri> 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 <ndevos> hagarth: I'm trying! you might want to reply to my email about community participation on our internal Red Hat list :)
13:39:04 <skoduri> 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 <ndevos> 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 <hagarth> ndevos: yes, I intend responding there :)
13:39:25 <jiffin> hagarth: In my opinion , today bug triage meeting peaked with its users
13:39:57 <ndevos> skoduri: would you be willing to help documenting the steps needed to receive bug notifications for a specific component?
13:40:04 <skoduri> ndevos, but that doesn't happen and hence asking why not enforce it?
13:40:32 <skoduri> ndevos, sure..I shall try ..but ofcourse with your help :)
13:40:37 <hagarth> jiffin: we need higher peaks, don't we? this looks like a local maxima to me :)
13:40:44 <ndevos> skoduri: because I prefer an opt-in mechanism that works for non Red Hat contributors too :)
13:41:30 <ndevos> #action skoduri and ndevos will document how people can get bug notifications for specific components
13:41:30 <skoduri> even now we can involve non Red Hat contributors...we just need to know who are interested in :)
13:41:52 <skoduri> but yeah I think we should move to group traige ;)
13:42:13 <ndevos> 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 <ndevos> yeah, still 18 minutes left for the triage itself, lets start that
13:43:07 <ndevos> #topic Group Triage
13:43:30 <ndevos> #info 18 bugs have been untriaged and need to be handled in this meeting
13:43:33 <ndevos> #link https://public.pad.fsfe.org/p/gluster-bugs-to-triage
13:43:52 <ndevos> when you triage a bug, put your name in front of the bug
13:44:21 <ndevos> 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 <hagarth> ndevos++
13:49:55 <ndevos> wohoo!
13:50:49 <Manikandan> ndevos, in the list of triage bugs, 1276839 has patch posted already..
13:51:02 <Manikandan> Only the status of the BZ is not changed
13:51:32 <skoduri> Manikandan, it should also have keyword "Triaged"
13:51:41 <kkeithley_> so you can set the state to POST (and keyword Triaged)
13:51:58 <Manikandan> skoduri, kkeithley_ okay
13:52:53 <Manikandan> kkeithley_, done :-)
14:00:16 <ndevos> looks like we're almost done, great!
14:01:17 <ndevos> nobody else posted any "open floor" topics, and we're running out of time for todays meeting too
14:01:49 <ndevos> so, thank you all for your participation, and we'll repeat the exercise next week again
14:02:06 <ndevos> next week will be the regular time, 12:00 UTC :)
14:02:20 <ndevos> #endmeeting