12:06:04 <kshlm> #startmeeting Gluster Community Meeting 13-Apr-2016
12:06:04 <zodbot> Meeting started Wed Apr 13 12:06:04 2016 UTC.  The chair is kshlm. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:06:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:06:04 <zodbot> The meeting name has been set to 'gluster_community_meeting_13-apr-2016'
12:06:10 <kshlm> First up roll call!
12:06:14 <kshlm> #topic Roll call
12:06:23 * kshlm o/
12:06:25 <ira> Braided!
12:06:28 * rastar is here
12:06:30 * aravindavk is here
12:06:32 <ira> Maybe Onion? :)
12:06:57 <kshlm> ira ?
12:07:03 <ira> Rolls! :)
12:07:04 * rjoseph o/
12:07:12 <ira> (It is an awful joke.)
12:07:19 <kshlm> ira, :)
12:07:35 <kshlm> Let's start
12:07:50 <kshlm> #topic Next weeks meeting host?
12:07:53 <kshlm> Any volunteers?
12:08:26 * post-factum is here too
12:08:31 <rastar> kshlm: I will
12:08:39 <kshlm> Cool!
12:08:47 <kshlm> #info rastar to host next weeks meeting
12:08:50 <kshlm> Thanks rastar
12:09:04 <kshlm> #topic Last weeks AIs
12:09:14 <kshlm> #topic kshlm & csim to set up faux/pseudo user email for gerrit, bugzilla, github
12:09:18 <kshlm> Not done.
12:09:28 <kshlm> Taking this forward 1 more week.
12:09:40 <kshlm> #action kshlm & csim to set up faux/pseudo user email for gerrit, bugzilla, github
12:09:50 <kshlm> #topic jdarcy to share his notes from his Bangalore discussions with the community
12:10:00 <jdarcy> Not done, probably won't be done at this point.
12:10:00 <kshlm> jdarcy, Any updates on this?
12:10:21 <jdarcy> OTOH, the people who were in those discussions seem to be moving forward based on them in most cases.
12:11:01 <kshlm> It would be good to know what everyone is trying to do.
12:11:27 <jdarcy> How about changing the AI to be a general 4.0 status report?
12:11:39 <kshlm> Sure.
12:12:01 <kshlm> #action jdarcy to provide a genral Gluster-4.0 status update
12:12:36 <kshlm> #topic jdarcy to follow up on 3.6-maintainer situation
12:12:54 <jdarcy> I did talk to Raghavendra and Vijay about this.  Are either of them here?
12:13:05 <kshlm> hagarth just joined.
12:14:00 <jdarcy> Short version was that they felt 3.6 should be in maintenance mode, not cutting new releases unless there's a specific high-prio reason (e.g. security vuln).
12:14:27 <jdarcy> And therefore that there's no need to seek a more active maintainer.
12:14:31 <post-factum> so, at this point, you actually drop two branches, 3.5 and 3.6
12:14:41 <jdarcy> Paraphrasing here, apologies if that's not quite accurate.
12:15:19 <jdarcy> hagarth: Anything to add?
12:16:23 <jdarcy> Maybe we should have an AI to get the community leads (technical and otherwise) to join the community meeting.
12:16:41 <jdarcy> I'll be glad to take that one.
12:16:48 <kshlm> jdarcy, I agree with that.
12:17:20 <kkeithley> Isn't that kind of where 3.6 is now anyway?
12:18:08 <kshlm> I think the last couple of releases had very few new changes.
12:18:14 <kshlm> So the load isn't that great.
12:18:17 <jdarcy> kkeithley: Sort of, just reiterating the logic (as given) behind not seeking a more active maintainer.
12:18:27 <kshlm> It's just that the releases didn't happen on scheduled time.
12:18:55 <jdarcy> kshlm: Are there patches in the 3.6 branch that haven't been packaged into a release yet?
12:19:50 <post-factum> i see just 1 commit on top of 3.6.9
12:19:57 <kshlm> As of now, there's been just one new patch on top of 3.6.9
12:21:00 * ndevos finished lunch _o/
12:21:01 <jdarcy> kshlm: Just found it.  The gfapi one?
12:21:10 <kshlm> Yeah.
12:21:23 <kkeithley> we could (and should?) be backporting more fixes to 3.6.
12:21:41 <kkeithley> Unless we decide not to.
12:22:14 <ndevos> we should be backporting fixes to all stable branches...
12:22:19 <kshlm> Till we do the 3.8 release we should keep backporting fixes.
12:22:32 <jdarcy> I think that's going to be a long list.
12:22:51 <kshlm> Maybe once it becomes the n-2 release, we can slowdown/reduce the volume
12:23:16 <post-factum> maybe really just stick to security fixes?
12:23:30 <kshlm> But the branch has run out of steam now itself.
12:23:46 <jdarcy> git log --oneline origin/master --not v3.6.9 | wc -l  =>  2564
12:24:12 <ndevos> well, only backport bugfixes, not general improvements and features
12:24:22 <jdarcy> git log --oneline origin/master --not v3.7.10 | wc -l  => 1555
12:24:40 * post-factum noted "--not" key
12:24:53 <jdarcy> ndevos: Just sorting through the list to separate the two will be onerous.
12:25:35 <jdarcy> BTW that's part of why I'm not in favor of tracking new-feature code through Bugzilla.  If they were tracked separately it'd be easier to tell which is which.
12:25:45 <kkeithley> Has it run out of steam for real? Or only because nobody bothers to backport fixes to it? How do we get devs to automatically do backports to all the active branches?
12:26:10 <ndevos> new features in bugzilla should have the FutureFeature keyword, we can sort/select on that
12:26:33 <kkeithley> And if flogging dead horses, er, begging devs to do backports doesn't work, then we should stop kidding ourselves and make it official.
12:26:46 <jdarcy> ndevos: So we have a list of patches, then for each one we have to check Bugzilla for the FutureFeature flag?  Who's going to write that script?
12:26:47 <ndevos> I try to remind developers to backport bugfixes when I merge them in master... I do not think all maintainers do so
12:27:15 <kshlm> kkeithley, Nobody bothers IMO, it's not the base for a RHS release. Only fixes get backported when it needs to land in a RHS release.
12:27:42 <kkeithley> kshlm: then we should stop kidding ourselves about it.
12:28:05 <jdarcy> Seems related to the LTS-release discussion, where LTS ~= base for RHS.
12:28:19 <ndevos> jdarcy: it's not difficult to write that, could take maybe 30-60 minutes - check-bugs.py in the release-tools repo can be used as inspiration
12:29:11 <hagarth> jdarcy: agree with 3.6, we need to get into a reactive mode with 3.6
12:30:11 <jdarcy> ndevos: Does that 30-60 minutes count fixing all of the test-infra bugs that keep it from passing, or negotiating five rounds of changes with reviewers?
12:30:13 <ndevos> maybe the bug automation scripts can help here, gem and Manikandan work on that - it would be nice to have a reminder in the Gerrit review "please backport!"
12:30:57 <rastar> ndevos: better thing would be to have something in gerrit
12:31:02 <ndevos> jdarcy: it would be the filtered bz's that are candidates for backports?
12:32:15 <hagarth> kkeithley, ndevos: why fix issues in 3.6 if there is no demand?
12:32:47 <ndevos> hagarth: reduce the problems users can run into?
12:32:51 <kshlm> hagarth, Because it's a supported release
12:33:11 <post-factum> ndevos: the main advice, anyway, users get on 3.6 is to update to 3.7
12:33:36 <ndevos> If I would be a user, and I hit a known problem that is fixed in a newer release, I expect to see the fix in all supported releases
12:33:40 <hagarth> ndevos: what do we mean by "support"?
12:33:57 <hagarth> ndevos: wouldn't it be users requesting help explicitly rather than awaiting passively?
12:34:12 <kkeithley> So, at the risk of straying over the line between Community GlusterFS and RHGS, either we need buy in from Red Hat management that "the job" includes doing backports to all active branches of upstream GlusterFS. Or we admit to ourselves that any bug fixes to branches other than the so-called LTS (3.7 in this case) will only come from the community.
12:34:36 <ndevos> hagarth: for me support means actively fixing known bugs
12:34:51 <rastar> hagarth, if we are shipping through some channel, it does have some support expectations from users
12:35:19 <hagarth> ndevos: yes actively fixing known bugs for known consumers
12:35:49 <ndevos> also, I think that Samba follows a similar approach, and so does the linux kernel with its stable releases
12:35:54 <hagarth> ndevos, rastar: if everybody is happy with 3.6 hypothetically, do we want to disturb the equilibrium?
12:36:19 <hagarth> unless there is a critical fix, I don't see the need to disturb equilibrium
12:36:36 <hagarth> upgrading to newer releases always carries a risk for users
12:36:38 <kkeithley> hagarth: How do we measure demand?  And don't get me wrong, I have (as you may recall) argued from dropping 3.5 sooner, rather than waiting for 3.8.
12:36:53 <jdarcy> kkeithley: I think that's the key.  Developers need to be given time to do the backports, which are not always trivial.
12:36:58 <Manikandan> ndevos, sure, we will include this :)
12:37:09 <rastar> hagarth: if we have not backported around 2564 patches, may be a few of them are critical?
12:37:36 <hagarth> kkeithley: by checking the usual community metrics - requests in bugzilla, mailing lists etc.
12:37:51 <kkeithley> Is that really objective?
12:38:28 <hagarth> kkeithley: I think so ..I see very few problems being reported on release-3.6 or 3.5 .. so it worth spending our time and effort there?
12:38:41 <hagarth> rastar: I may have missed the context on 2564 patches ;)
12:38:51 <ndevos> #info 73 open bugs in 3.6 https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&f1=keywords&f2=version&o1=nowords&o2=regexp&product=GlusterFS&v2=^3.6
12:38:56 <kkeithley> I can look at downloads (http://download.gluster.org/pub/gluster/glusterfs/download-stats.html) not perfect, but better than nothing, and conclude what, if anything?
12:39:12 <rastar> hagarth: jdarcy pointed out that 2564 patches are missing from 3.6.9 when compared to master
12:39:22 <hagarth> ndevos: I think we need to poll the community about what we would want to fix in 3.6
12:39:41 <ndevos> I expect that many of those 73 bugs have been fixed in the master branch and maybe even in 3.7
12:39:42 <kkeithley> hagarth: well, again, I have actually argued for EOL-ing 3.5 earlier.
12:40:21 <hagarth> ndevos: how many of those bugs have seen an update in the last 180 days?
12:40:52 <rastar> hagarth: I agree with you is it worth spending time on it point. I would rather not promise any update at all and EOL them sooner.
12:40:54 <kkeithley> For the record, I'd be perfectly happy with 3.5 EOL now, and once 3.8 ships, and only doing critical (e.g. security, memory leak) fixes on 3.6.
12:41:01 <ndevos> hagarth: thats difficult to say, somehow they all got updated in 2016...
12:41:05 <hagarth> kkeithley: I get that and I am all in favor of backporting too. But given how stretched we are, I am wondering if we should do away with our monthly release cadence and switch to a more reactive mode.
12:41:08 <post-factum> kkeithley: 3.6.9, rhel/centos 7 downloads: 1896. i cannot believe users of new el7 download 3.6 intentionally
12:41:20 <post-factum> kkeithley: otoh, if those are 1896, where are bugreports?
12:41:31 <post-factum> s/1896/1896 updates/
12:42:02 <ndevos> post-factum: there are at least 2 bug reports for 3.6.9, 3 for 3.6.8
12:42:07 <kkeithley> post-factum: like I said, it's not perfect. ;-)
12:42:12 <hagarth> my vote would be to poll the community to see if they are affected by lack of patches in release-3.6 and release-3.5
12:42:41 <kkeithley> and once 3.8 ships only doing critical (e.g. security, memory leak) fixes on 3.6.
12:42:49 <hagarth> I need to rush out on a morning errand, but will be happy to continue this conversation later
12:42:57 <hagarth> kkeithley: +1
12:43:06 <ndevos> hagarth: I do not think we need to care about 3.5 at this point, my announcement earlier today should have been pretty clear about that
12:43:26 <hagarth> ndevos: sorry, lagging behind on emails/IRC atm
12:43:33 <kshlm> Okay.
12:43:49 <hagarth> maybe we can poll about 3.6
12:43:54 <kshlm> So we need to re-evaluate our support and release strategies
12:43:56 <ndevos> kkeithley: that sounds reasonable, but we still need the maintainers+developers to judge if patches need a backport
12:44:00 <hagarth> will bbl
12:44:08 <kshlm> hagarth, would you be willing to take an AI to continue this discussion
12:44:16 <hagarth> kshlm: please go ahead
12:44:24 <kshlm> Thanks hagarth
12:45:17 <kshlm> #action hagarth to take forward discussion on release and support strategies (onto mailing lists or another IRC meeting)
12:45:22 <kshlm> Onto the next AI.
12:45:33 <kshlm> #topic ndevos to send out 3.5.9 announcement
12:45:38 <ndevos> yes, did that!
12:45:40 <kshlm> I think ndevos did it.
12:45:48 <kshlm> Good.
12:45:56 <ndevos> #link http://www.gluster.org/pipermail/announce/2016-April/000055.html
12:46:00 <kshlm> Thanks ndevos.
12:46:16 <kshlm> #topic ndevos to update events page re: Incontro DevOps
12:46:21 <kshlm> This was done as well
12:46:36 <ndevos> #link http://gluster.readthedocs.org/en/latest/presentations/
12:46:37 <kshlm> I saw a PR on the glusterweb or the glusterdocs repo.
12:46:48 <kshlm> Thanks again ndevos
12:46:55 <kshlm> Done with the AIs
12:47:03 <kshlm> #topic GlusterFS-3.7
12:47:23 <kshlm> So I'm waiting on regression to complete on a patch so that I can finally do the release.
12:47:39 <kshlm> It's failed spuriously for like 5 times till now.
12:47:55 <kshlm> Hopefully I get to tag the release later today.
12:48:25 <kshlm> We've discussed enough about 3.6, so I think we can skip it for today.
12:48:39 <kshlm> ndevos, Would you like to discuss anything on 3.5?
12:48:47 <kshlm> Or can we skip it as well?
12:49:04 <ndevos> kshlm: we can skip that, people should just read the announcement of 3.5.9
12:49:17 <kshlm> Okay.
12:49:30 <kshlm> So we're done for today.
12:49:37 <kshlm> Nothing on Open floor.
12:49:41 <post-factum> not rly
12:49:44 <post-factum> :)
12:49:47 <kshlm> Does anyone else have anything to add.
12:49:52 <kshlm> post-factum, :)
12:49:56 <post-factum> xglfs! i want more feedback
12:50:05 <kkeithley> I did send out an RFC email about nfs.disable default to 'on'
12:50:06 <aravindavk> kshlm: golang support in build machines
12:50:13 <kkeithley> for 3.8
12:50:24 <post-factum> also, if itisravi is here, i'd like to ping him for https://bugzilla.redhat.com/show_bug.cgi?id=1318289, but no
12:50:25 <glusterbot> Bug 1318289: low, unspecified, ---, ravishankar, NEW , [RFE] Add arbiter brick hotplug
12:50:31 <kshlm> aravindavk, I saw your mail. We need misc to be back to get it done.
12:50:59 <aravindavk> kshlm: ok
12:51:22 <kshlm> Before I forget..
12:51:26 <ndevos> aravindavk: I did not see the email, was that on gluster-infra?
12:51:52 <kshlm> #action jdarcy will get more technical and community leads to participate in the weekly meeting
12:51:52 <post-factum> btw, xglfs was moved under gluster org on github
12:52:02 <jdarcy> Yay!
12:52:06 <kshlm> post-factum, yay!
12:52:09 <ndevos> aravindavk: we could add more tests in the CentOS CI too, so I wonder why you would need golang?
12:52:49 <kshlm> ndevos, The 3.8 rest server is implemented in go
12:52:53 <aravindavk> ndevos: golang for the new feature REST APIs and Eventing
12:52:53 <ndevos> one of the next steps with xglfs is to start testing it more, and compare performance/functionality with our current FUSE implementation
12:53:37 <ndevos> aravindavk: ah, right, its an external repo, wasnt it?
12:55:07 <jdarcy> Performance testing is going to be quite critical if we want to consider using it to replace the current GFAPI.  I'll be glad to help with that.
12:55:22 <post-factum> #link https://github.com/gluster/xglfs
12:55:29 <post-factum> jdarcy: you are welcome
12:55:34 <aravindavk> ndevos: it was. But Eventing related code needs integration with Gluster code, so it is difficult to manage externally
12:56:29 <ndevos> aravindavk: hmm, okay, I guess we need a proposal for the building/testing/packaging then?
12:57:00 <jdarcy> BTW, I'm reprising my distributed-storage-performance talk from LISA at BBLISA tonight.
12:57:02 <kkeithley> replace the current GFAPI?  The current fuse bridge isn't gfapi-based.
12:57:17 <jdarcy> kkeithley: The current FUSE bridge.  IRTE.
12:57:25 <ndevos> jdarcy: how about trying to get xglfs to become the default fuse mount executable for Gluster 4.0?
12:57:30 <aravindavk> ndevos: my patch addresses building/packaging and rpm stuff. But needs golang to be installed http://review.gluster.org/13977
12:58:11 <jdarcy> ndevos: I'm neither for nor against that.  I think I'd want to see a performance baseline first, to see if it's feasible.
12:58:17 <ndevos> aravindavk: ok, just note that not all distributions we support come with golang by default, it may be tricky
12:58:27 <kkeithley> irte? Institute of Road Transport Engineers
12:58:32 <post-factum> :D
12:58:33 <jdarcy> I Regret The Error
12:58:46 <post-factum> no, road engineers are better
12:58:48 <ndevos> jdarcy: yes, we need to gain more experience with xglfs first
12:59:15 <aravindavk> ndevos: ./configure --disable-restapi --disable-events  options available
12:59:38 <ndevos> aravindavk: yeah, I'll have a look at the patch later
12:59:45 <jdarcy> I think xglfs is really *really* promising, but this is core infrastructure that has been tuned and tweaked to handle lots of edge cases, so I want to be careful.
13:00:33 <post-factum> maybe, testing xglfs extensively will bring some improvements in gfapi code as well
13:00:39 <jdarcy> Quite likely.
13:00:44 <kkeithley> indeed
13:00:48 <ndevos> jdarcy: indeed, and one of my plans is to run the regression tests with xglfs too :)
13:01:17 <kkeithley> it never hurts to shine a little light into dark places.
13:01:17 <jdarcy> We could probably run the current GFAPI-specific regressions pretty easily.
13:01:23 <kshlm> I'm gonna end the meeting. It's time.
13:01:38 <jdarcy> kshlm: Thanks!  Sorry for derailing so much.
13:01:40 <post-factum> ok thx kshlm
13:01:49 <kshlm> The discussion can be continued on gluster-dev (or here doesn't matter)
13:01:52 <kshlm> #endmeeting