12:02:19 <ndevos> #startmeeting
12:02:19 <zodbot> Meeting started Tue Oct 14 12:02:19 2014 UTC.  The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:02:35 <ndevos> Agenda for today: https://public.pad.fsfe.org/p/gluster-bug-triage
12:02:40 <ndevos> #topic Roll Call
12:02:53 * kkeithley_ is here
12:02:56 <ndevos> Hi, I'm here, *live* from LinuxCon Europe
12:03:19 <kkeithley_> ndevos++
12:07:17 <kkeithley_> hmmm, poor turnout
12:07:23 <kkeithley_> :-(
12:09:51 * nixpanic <- actually ndevos too
12:10:17 <nixpanic> for some reason my irc remote irc client dies not like being on flakey network
12:10:43 <nixpanic> sorry for the delay, I missed the roll call, exceopt for kkeithley's answer
12:11:31 <ndevos_> #topic Status of last weeks action items
12:11:50 <ndevos_> #topic hchiramm to make sure that bugs@gluster.org becomes the default owner of new bugs
12:11:58 <ndevos_> hchiramm_: are you here?
12:12:20 <ndevos_> hmm, I guess not...
12:12:46 <ndevos_> #action hchiramm_ should be online when his topics get discussed
12:13:05 <ndevos_> we'll skip the points from hchiramm_ on the agenda, there is enough listed..
12:13:21 <ndevos_> #topic Humble and ndevos will figure out how to get "a report on how many bugs exist in each version of glusterfs
12:13:36 <ndevos_> http://goo.gl/VxQPwc is one such report, would that be useful?
12:13:46 <jdarcy> Apparently everyone's too busy looking for coding-style issues.
12:13:46 <ndevos_> (Humble = hchiramm_)
12:13:54 <ndevos_> :P
12:14:23 <ndevos_> we'll make it short then :)
12:14:46 <ndevos_> I guess the report is okay, I just have no idea where hchiramm_ would want it
12:14:52 <ndevos_> #topic     EVERYONE to review http://www.gluster.org/community/documentation/index.php/How_to_clone and give feedback to Humble, or update the page themselves
12:15:21 <ndevos_> there have been a few updates on the page, I think it mostly looks good
12:15:27 <ndevos_> any objections?
12:15:43 <ndevos_> I'll count that as a 'no'
12:15:47 <ndevos_> #topic hagarth will look for somebody that can act like a bug assigner manager kind of person
12:16:01 <ndevos_> hagarth isnt here, and I have not heard anything from him about this
12:16:09 <ndevos_> anyone else got more details?
12:16:11 <jdarcy> "Bug wrangler"?
12:16:20 <ndevos_> yes, something like that
12:16:24 <kkeithley_> other than he's out on paternity leave
12:17:07 <ndevos_> yes, I do not expect him to get back on this within the next weeks, but maybe (the missing) davemc got something
12:17:11 <ndevos_> oh well...
12:17:21 <ndevos_> #topic pranithk to report how his team is assigning triaged bugs
12:17:32 <ndevos_> aaaand he's not here either :-/
12:18:11 <ndevos_> I wonder if we should discuss more things, lets see if we get some traction...
12:18:15 <ndevos_> #topic Add distinction between "problem reports" and "enhancement requests"
12:18:49 <ndevos_> for us, bugs are bugs, and we do not really make a distinction between feature requests or problems
12:19:12 <ndevos_> the Bug Triage guidelines should get adapted for that, somehow
12:19:17 <kkeithley_> well, we don't have featurezilla to track features/enhancements
12:19:23 <ndevos_> any ideas on how that can be done?
12:19:29 <jdarcy> In the past, we've use "[FEAT]" in the summary.  Maybe better as a tag?
12:19:36 <ndevos_> http://www.gluster.org/community/documentation/index.php/Bug_triage
12:20:07 <ndevos_> [FEAT] would do, there is also a FutureFeature keyword - whatever we choose, we should stick to it and document
12:21:06 <ndevos_> nobody has any opinions on this?
12:21:49 <ndevos_> #agreed More discussion on featurezilla needed
12:21:51 <kkeithley_> Nobody nags when features on the gluster.org feature page don't get attention. But likewise, nobody does anything when feature bugs don't get addressed.
12:21:54 <jdarcy> "FutureFeature" is already documented as a keyword in Bugzilla.
12:22:07 <kkeithley_> and RHS PM doesn't ever look at either, AFAICT
12:22:30 <kkeithley_> and RHS PM seems to dominate when it comes to deciding what features get atttention
12:22:34 <ndevos_> I dont think we care about RHS during this meeting ;)
12:22:45 <kkeithley_> oh, I know
12:23:01 <kkeithley_> but figuring how features will get attention
12:23:22 <kkeithley_> when RHS PM dictates where resources get allocated is a "problem"
12:23:23 <ndevos_> I hope people submit feature pages when they propose a feature, at the same time, they should probably create a bug for it
12:24:15 <ndevos_> oh, yes, PM (product management) for the RHS developers, but there are some people that would like to implement/request some features
12:24:19 <kkeithley_> then there are the people who submit feature requests and then disappear, expecting the feature to magically happen
12:24:28 <jdarcy> Hopefully, as we evolve toward a stronger "release shepherd" role upstream, people will be held to a higher standard wrt feature pages and BZ bugs pointing to them.
12:24:49 <ndevos_> we should be able to track feature requests, and other interested users can follow that, or help with providing it
12:25:52 <ndevos_> I've tried to sort some features in the wiki, some proposals that are not worked on for a release yet - and would welcome volunteers
12:26:21 <ndevos_> like http://www.gluster.org/community/documentation/index.php/Features#Proposed_Features.2FIdeas
12:26:44 <jdarcy> Feature pages are good for details, but IMO bugs are better for tracking "depends on" relationships, priority, completion status, etc.
12:27:02 <jdarcy> I could submit a proposal for that, give people some new reasons to kick me around a bit.
12:27:02 <ndevos_> others seem to have extended that list, which is good, I think
12:27:33 <ndevos_> we definitely should have bugs before or as soon as there is a feature page
12:28:07 <ndevos_> many users file a bug for a feature request, that bug should get linked to a feature page when there are enough details
12:28:16 <jdarcy> Agreed.
12:28:51 <ndevos_> #agreed Feature Requests should get filed as a bug, when a feature page gets available, link it in the bug report
12:29:57 <ndevos_> I'll make a note about that later, and will send an email to the -devel list for the [FEAT] or FutureFeature keyword
12:30:24 <jdarcy> I also suggest requiring a back-link from the feature page into BZ, as soon as that becomes possible.
12:30:33 <ndevos_> #action ndevos will send an email about FutureFeature/[FEAT] marking of feature requests to the -devel list
12:30:46 <ndevos_> oh, yes, of course
12:31:17 <ndevos_> those should be done while updating the bug, and many should have a link to the bug(s) already
12:32:06 <ndevos_> #action ndevos_ will update the feature template to include a link to the bug for the feature
12:32:21 <ndevos_> #topic Group Triage
12:32:44 <ndevos_> nobody proposed any bugs for triage, I guess all bugs are good?
12:32:56 <ndevos_> #topic Bugs marked for group triage (NEEDINFO from gluster-bugs@redhat.com)
12:33:12 <ndevos_> there is one bug in the http://goo.gl/S9VQgQ report
12:33:20 <ndevos_> https://bugzilla.redhat.com/show_bug.cgi?id=1140818
12:34:08 <ndevos_> lala put it there, but is not here... I'm not sure what he needs from this 'group'
12:34:29 <jdarcy> What about https://bugzilla.redhat.com/show_bug.cgi?id=1140818 ?
12:34:44 <kkeithley_> should it be filed against posix (instead of core)?
12:35:03 <ndevos_> thats the same bug, jdarcy
12:35:12 <ndevos_> I would say afr...
12:35:47 <jdarcy> Definitely looks like AFR to me.
12:35:48 <ndevos_> steps to reproduce seem simple enough
12:36:23 <jdarcy> Since it's loss of data availability, I'd put severity at high, but I think according to http://www.gluster.org/community/documentation/index.php/Bug_triage it would be medium.
12:36:23 <ndevos_> jdarcy: would the information in the bug be enough for an AFR developer to have a look at it?
12:36:42 <jdarcy> ndevos: I think so.
12:37:31 <ndevos_> okay, marked as Triaged and moved to 'replicate' now
12:37:54 <ndevos_> kept the severity, I dont think anyone really uses that, but feel free to change :)
12:37:56 <jdarcy> Then again, Lalatendu flagged it with "needinfo".  Maybe we need info on the "need info" (e.g. *what* info).
12:38:29 <ndevos_> oh, yes, indeed - I'll post the question to him
12:40:02 <ndevos_> well, I guess he'll just clear the needinfo as we should be done with that one
12:40:19 <kkeithley_> oh, btw, in addition to thur and fri last week being holidays in India, much of the BLR staff were given comp time yesterday and today after the Denali release. That's probably why nobody is here.
12:40:19 <ndevos_> #topic New bugs to triage (filed since last week)
12:40:39 <ndevos_> oh, again? wasnt that last week too?
12:40:53 <ndevos_> last weeks NEW bugs: http://goo.gl/0IqF2q
12:41:09 <kkeithley_> oh, never mind. I've lost a week. And my mind
12:42:15 <ndevos_> you guys want to triage those bugs from last week after the meeting?
12:42:39 <kkeithley_> sure
12:42:52 <ndevos_> cool, thanks!
12:43:17 <kkeithley_> do you have a link to the list handy?
12:43:25 <jdarcy> Real list of bugs new this week: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&chfield=%5BBug%20creation%5D&chfieldfrom=-7d&chfieldto=Now&classification=Community&list_id=2917885&product=GlusterFS&query_format=advanced
12:43:56 <ndevos_> one week is different from 7 days?
12:45:00 <ndevos_> ah, no, the difference is that some bugs have been triaged, and do not show up on the 1st list
12:46:04 <ndevos_> and bugs in 3.4 that need to get triaged:     https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&f2=version&o1=nowords&o2=regexp&v1=Triaged&v2=^3.4
12:46:35 <ndevos_> just replace the 3.4 at the end of the URL to 3.5, 3.6 or mainline to get an other version
12:47:05 <jdarcy> So we have five bugs that have appeared in the last week and don't have the "Triaged" keyword?
12:47:15 <ndevos_> jdarcy: yes, correct
12:47:40 <ndevos_> after someone set the Triaged keyword, it is up to the sub-maintainer(s) and developers to pick those bugs and work on them
12:48:08 <ndevos_> pranith wanted to inform us today how that has been working the last few weeks for his team, its a shame he's not here
12:48:50 <ndevos_> he would for example look at https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&o1=nowords&v1=Triaged&component=replicate
12:50:05 <jdarcy> https://bugzilla.redhat.com/show_bug.cgi?id=1151397 looks like a backport request for a bug already fixed in master.  Should we have a separate keyword for that?
12:50:36 <ndevos_> ah, yes, I normally add the Patch keyword and the Gerrit URL to the patch
12:52:00 <jdarcy> That would be good, but a keyword would make it easier to filter them out from the triage list.
12:54:05 <kkeithley_> hmmm. Looks like he's filing bugs against his DHT mega patch for 3.4. Which some parts of that patch are still waiting for +1 before I can merge
12:54:11 <ndevos_> #action ndevos will add a note about the Patch keyword for backports in the Bug Triage Guidelines
12:55:50 <ndevos_> #action ndevos will add a note about the Patch keyword for backports in the "How to clone" wiki page
12:56:38 <ndevos_> jdarcy: do you have a bugzilla filter that shows the open bugs with the Patch keyword?
12:56:49 <jdarcy> Not handy.
12:57:07 <ndevos_> okay, no need to get it then
12:57:38 <ndevos_> I guess such a list would be useful for new contributors, they can test their Gerrit skillz
12:58:09 <ndevos_> #topic Open Floor
12:58:21 <ndevos_> #topic Preference on bugzilla notifications? Emails, RSS-feeds, glusterbot, weekly blog posts...
12:58:39 <ndevos_> do you have any preference on bugzilla notifications?
12:59:11 <ndevos_> personally I am happy with the bugzilla searches
12:59:26 <jdarcy> Definitely not email.  There's too much other BZ spam for it to get lost in.
12:59:35 <kkeithley_> about that list of bugs for 3.4.  bugs written against, e.g. 3.4.0-alpha, what do we want to do with those? Presume they're fixed in one of the intervening releases?  Try to get someone (a developer) to look at them and agree that they're probably fixed?
13:00:04 <jdarcy> RSS feeds are an interesting possibility.  Haven't tried that approach, and I do check my feeds at least daily but not constantly.
13:00:10 <kkeithley_> yeah, email is not a good choice
13:00:13 <ndevos_> kkeithley_: yes, someone should look at it and update them - the user that filed it would probably like to know
13:00:46 <ndevos_> some RSS-Feeds are listed here: http://www.gluster.org/community/documentation/index.php/Bugzilla_Notifications#RSS_Feeds
13:01:09 <jdarcy> I'll give those a try, report back next week.
13:01:32 <ndevos_> #action jdarcy will try the RSS-feeds and will report next week
13:01:36 <ndevos_> cool!
13:01:48 <ndevos_> if you need more rss-feeds, let me know
13:02:59 <jdarcy> What should I *do* with new items?  Sort of pre-triage, either adding to a list for the meeting or pushing back for more info?
13:02:59 <ndevos_> or, you can create them yourself, check a bugzilla report, the feed-url is listed at the bottom
13:03:44 <ndevos_> yes, look at the bugs if they contain sufficient info (yes, add the Triaged keyword or, no, ask for logs, ...)
13:04:14 <ndevos_> make sure the bugs are filed against the correct component, add useful keywords (EasyFix, Documentation, ...)
13:04:32 <jdarcy> OK, I'll do my best.
13:04:38 <ndevos_> :D
13:04:55 <ndevos_> jdarcy: http://www.gluster.org/community/documentation/index.php/Bug_triage contains the full process
13:05:29 <ndevos_> #topic Last Call for topics!
13:05:40 <ndevos_> anything else that we can/need to discuss now?
13:05:42 <jdarcy> I'll try to be conservative about adding Triaged myself, since that effectively hides it from the rest of the group.
13:06:33 <ndevos_> Triaged should add the bug to a list that the sub-maintainers check (me for nfs, pranith for replicate, etc)
13:07:11 <ndevos_> it should not hide the bugs, it should show that there is some progress with the bug - and users like to see that
13:07:33 <ndevos_> (well, not all users that get reminded about their 1 year old bugs, but most users)
13:08:21 <kkeithley_> heh, 100+ bugs against 3.4 with no progress in a year. hmmmm
13:08:22 <ndevos_> jdarcy: any bug that you can put in a more 'correct' state, or mark triaged should be good :)
13:08:32 <jdarcy> Well, most of the searches on https://public.pad.fsfe.org/p/gluster-bug-triage exclude that keyword, so people who rely on checking those five minutes before this meeting won't see stuff marked during the week.  Or maybe that's the point.
13:08:55 <ndevos_> kkeithley_: yeah... I did a big cleanup for 3.5, still 41 bugs left - and those are only the untriaged ones
13:09:28 <ndevos_> jdarcy: yes, it's indeed intentional, the is the 'bug triage meeting' :D
13:10:00 <ndevos_> jdarcy: we dont have a 'bug assigning meeting', but those would only list bugs that have the Triaged keyword
13:10:05 <kkeithley_> how about I close all the 3.4 rdma bugs?  It works in 3.5. It was "iffy" in 3.4. Anyone who wants rdma should use 3.5? Seem reasonable?
13:10:22 <ndevos_> kkeithley_: I think thats reasonable
13:10:55 <ndevos_> kkeithley_: I've seen an email from a developer that would like to backport some rdma fixes to 3.5, so there is still some improvement needed
13:10:56 <kkeithley_> I'll close them with an appropriate comment to that effect then. Thanks
13:11:09 <ndevos_> sure, sounds good to me
13:11:15 <kkeithley_> yeah, for 3.5. sure
13:12:18 <ndevos_> okay, I think thats it for today, lets hope we have more participants next week
13:12:21 <ndevos_> #endmeeting
13:12:28 <ndevos_> oh, and of course that fails :-/
13:13:50 <jdarcy> C ya.
13:13:56 <ndevos_> thanks jdarcy and kkeithley_!
13:14:05 <kkeithley_> yw, adios
13:14:13 <ndevos> #endmeeting