12:01:39 <rastar> #startmeeting Weekly Community meeting 4th May 2016
12:01:39 <zodbot> Meeting started Wed May  4 12:01:39 2016 UTC.  The chair is rastar. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:01:39 <zodbot> The meeting name has been set to 'weekly_community_meeting_4th_may_2016'
12:01:55 <rastar> #topic Roll call
12:02:13 * jdarcy is here
12:02:30 * jiffin is here
12:02:31 * atinm raises his hands
12:02:37 * kkeithley is here
12:02:48 * anoopcs is here
12:02:48 * karthik___ is here
12:03:10 * rjoseph is here
12:03:19 * ndevos is at home
12:03:31 <rastar> Let us wait for some more time
12:03:33 <rastar> ndevos: :)
12:04:42 <jdarcy> Apparently "here" overlaps with ndevos's home.  Got any coffee?
12:05:06 <ndevos> yes, coffee is at my desk too
12:05:34 <rastar> Ok, let's start
12:05:50 <rastar> The link to the agenda in in the topic..
12:06:08 <rastar> #topic Last Weeks AIs
12:06:20 <rastar> #topic kshlm & csim to set up faux/pseudo user email for gerrit, bugzilla, github
12:06:58 <rastar> We don't have either kshlm or csim here
12:07:10 <ndevos> we already have bugs@gluster.org in bugzilla.... for *long*
12:07:10 <rastar> I don't have any updates on this, moving on
12:07:35 * skoduri is here
12:07:41 * overclk is here..
12:08:00 <rastar> ndevos: I don't remember why this was requested, do you?
12:08:24 <kkeithley> I don't like the idea of using bugs@gluster.org for the patch-posted-to-gerrit updates to BZs
12:08:31 <kkeithley> seems like it could be abused
12:08:37 <jdarcy> I think because it was slightly un-kosher to have all those changed-status updates coming from Avati or (more recently) Vijay.
12:08:41 <kkeithley> although I'm not sure how
12:08:46 <atinm> #info agenda is here : https://public.pad.fsfe.org/p/gluster-community-meetings
12:09:11 <rastar> jdarcy: Thanks :)
12:09:23 <kkeithley> if only because Avati doesn't work _here_ any more
12:09:56 <ndevos> oh, posts to bugzilla should not be tied to any persons account
12:10:04 <kkeithley> exactly
12:10:07 <rastar> yes, something like gluster.ant@gluster.org would be better
12:10:13 <kkeithley> robo posts
12:10:20 <ndevos> bugs@gluster.org would work for me, not sure why kkeithley doesnt like it
12:10:46 <kkeithley> if it can't be abused then I'm not opposed to bugs@gluster.org
12:11:05 <ndevos> anything can be abused...
12:11:25 * kkeithley rolls his eyes.
12:11:41 <kkeithley> _easily_ abused
12:12:10 <jdarcy> Let's move on.
12:12:15 <rastar> ok
12:12:25 <rastar> #topic jdarcy to provide a general Gluster-4.0 status update
12:12:30 <jdarcy> Done.
12:12:42 <rastar> jdarcy: yes, we saw the mail :)
12:12:45 <ndevos> and yes, thanks for that jdarcy!
12:12:49 <rastar> anything to add here?
12:12:52 <jdarcy> Nope.
12:13:12 <rastar> I forgot to set AI on faux user
12:13:19 <rastar> #action kshlm & csim to set up faux/pseudo user email for gerrit, bugzilla, github
12:13:27 <atinm> We
12:13:33 <atinm> oops
12:13:38 <rastar> #topic jdarcy will get more technical and community leads to participate in the weekly meeting
12:13:54 <jdarcy> I've nagged and whined as much as I'm going to.  We can retire the item.
12:14:05 <rastar> I was going to say the same
12:14:17 <rastar> moving on..
12:14:18 <lpabon> sorry for being late.. kids just got on the bus
12:14:23 <jdarcy> Let me be clear: I've nagged and whined *on that topic* ...   ;)
12:14:26 * post-factum joins better late than never
12:14:47 <rastar> hello lpabon post-factum
12:14:55 <rastar> #topic hagarth to take forward discussion on release and support strategies (onto mailing lists or another IRC meeting)
12:15:17 <ndevos> oh, he sent an email
12:15:19 <rastar> I saw hagarth_ 's reply on the same, we need more responses on that thread
12:15:48 <rastar> Especially now that we have branched 3.8
12:16:32 <ndevos> yeah, pranith (where is he?) had a proposal too
12:17:04 <rastar> ndevos: pranith could not join today
12:17:13 <rastar> I was talking about the same thread that he started
12:18:20 * rastar is not able to search for that email
12:19:07 * ndevos also can not find the mail
12:19:33 <rastar> subject was "RFC for change in release model"
12:19:34 <atinm> its on the maintainers list I believe and I don't know the archive link for it
12:19:49 <atinm> does anyone?
12:19:51 <ndevos> #link http://www.gluster.org/pipermail/maintainers/2016-April/000645.html
12:20:01 <rastar> ndevos: thanks!
12:20:18 <atinm> ndevos, you are super fast!
12:20:22 <ndevos> and Vijays related one:
12:20:24 <ndevos> #link http://www.gluster.org/pipermail/maintainers/2016-April/000679.html
12:21:05 <rastar> do we need an AI on this again?
12:21:10 <post-factum> welcome pranithk1
12:21:18 <pranithk1> post-factum: thanks
12:21:37 <rastar> I think the mails are sufficient
12:22:00 <ndevos> rastar: we need to reach a decision at one point, we probably should check next week if we have one
12:22:13 <rastar> ndevos: ok
12:22:20 <rastar> #action hagarth to take forward discussion on release and support strategies (onto mailing lists or another IRC meeting)
12:22:37 <rastar> the next topic I am not sure if it was resolved in last meeting
12:22:47 <rastar> #topic amye to check on some blog posts being distorted on blog.gluster.org, josferna's post in particular.
12:23:09 <pranithk1> ndevos: tell me when I can talk about different release strategy. There are somethings I don't know what to do either.
12:23:32 <rastar> pranithk1: now is the time..
12:24:23 <pranithk1> okay, the thinking is we need a way to keep stable branches stable
12:24:44 <pranithk1> and we also don't want to make users wait for ~6-7 months for new stuff to try out
12:24:47 <pranithk1> how do we do that?
12:25:19 <pranithk1> So the proposal is to have a 3 month release cycle for minor release where one will be stable release the next one is for new components to be included
12:25:27 * msvbhat arrives very late to the meeting
12:25:51 <pranithk1> this shorter one will only be there for 3 months until next stable release after which stable version takes over.
12:26:09 <pranithk1> but there were questions like how many releases do we support at any point
12:26:13 <ndevos> from my understanding, 3.8 would be the stable release, 3 months later 3.9 gets released and 3.10 (or 4.0) would be the next stable release
12:26:19 <pranithk1> won't we have to backport 2-3 releases etc
12:26:33 <pranithk1> ndevos: yes, that is the thinking
12:26:53 <post-factum> so, this model is somewhat linux kernel has
12:26:53 <ndevos> and we'd "support" 3 stable releases, giving users a 1,5 year of bugfixes for teh stable versions
12:27:33 <rastar> ndevos: 3 stable releases mean 3 backports for every patch which is a bug fix
12:27:40 <pranithk1> ndevos: this increases backporting burden though
12:27:55 <kkeithley> three stable releases = 3.8, 3.10, 3.12?
12:27:57 <ndevos> one of the difficulties with our project, is that users are very conservative in updating, they do not want to have (any) downtime of their storage services
12:28:09 <ndevos> kkeithley: yeah, just like we do now
12:28:20 <atinm> I had a question here in the email thread
12:28:21 <kkeithley> Or three releases, 3.8, 3.9, 3.10
12:28:27 <atinm> how many releases we maintain in that case?
12:28:31 <post-factum> ndevos: personally me would happily update to new release immediately. we need new features
12:28:37 <ndevos> pranithk1: backports should *only* be about bug fixes, features are not suitable for stable backports
12:29:03 <pranithk1> ndevos: that makes things easier, you are correct
12:29:05 <ndevos> post-factum: I'm sure you will find yourself in the minority :)
12:29:20 <rastar> ndevos: but there are many bug fix patches
12:29:24 <post-factum> ndevos: what i find constantly here is users asking for support for 3.2 branch
12:29:45 <post-factum> ndevos: that is not what you want to happen usually
12:30:10 <ndevos> pranithk1: when we stick to 6 month releases, users have more options to move to newer versions, developors should encourage users to uprgade if they need new features
12:30:29 <aravindavk> pranithk1: interval between stable releases? 6month or 1 year?
12:30:32 <pranithk1> ndevos: but 6 months seem too high for small new features
12:30:36 <ndevos> post-factum: I think some version of debian still ships 3.2 :-/
12:30:43 <pranithk1> aravindavk: You suggest :-)
12:30:55 * hagarth_ o/
12:31:26 <post-factum> one stable release per 3 months?
12:31:31 <rastar> I prefer lesser delta in code, hence 3 months
12:31:43 <aravindavk> pranithk1: support of stable version ends when next stable version released or multiple stable version can exist?
12:32:03 <ndevos> post-factum: that would require us to maintain many stable versions if we want to offer 1.5 year "support" for stable versions
12:32:42 <post-factum> ndevos: you could choose 3 LTS and support them
12:33:17 <pranithk1> aravindavk: I am thinking ending, not multiple stable versions, but ndevos is saying 3 stable versions will be supported
12:33:34 <ndevos> aravindavk: I do not think users are comfortable with updating their storage once every year... (but I'm also not sure when/who/why picked the 1.5 year interval)
12:33:53 <rastar> ndevos: what about having 1 stable version for 1.5 years and other releases every 3 months
12:34:31 <spalai> agree with rastar
12:34:44 <post-factum> so, 1 LTS instead of 3?
12:34:49 <rastar> post-factum: yes
12:34:55 <post-factum> ok, rastar++
12:35:03 <spalai> rastar++
12:35:04 <glusterbot> spalai: rastar's karma is now 3
12:35:13 <post-factum> hey, bot
12:35:16 <post-factum> rastar++
12:35:16 <ndevos> rastar: that means anyone wanting to use a new feature, will have to keep updating until at least the next stable version gets out
12:35:16 <glusterbot> post-factum: rastar's karma is now 4
12:35:46 <post-factum> ndevos: that also means users won't face major issues on major update
12:36:03 <rastar> ndevos: yes, but 1.5 years of wait is not much in storage world
12:36:11 <post-factum> ndevos: small incremental updates bring less pain
12:36:28 <rastar> post-factum: I really want that
12:36:33 <ndevos> post-factum: any upgrade brings a risk, maybe some features get deprecated/replaced, or whatever
12:36:50 <rastar> even as a developer debugging becomes difficult when many new features come in at once
12:37:09 <post-factum> ndevos: for sure, but in 3 months there could be not so many critical changes unlike in 1,5 years
12:37:11 <ndevos> post-factum: not all our users read the documentation, if we even manage to strangle release notes from the developers
12:37:26 <post-factum> ndevos: not reading docs is not an excuse!
12:37:44 <rastar> post-factum++
12:37:45 <glusterbot> rastar: post-factum's karma is now 1
12:38:08 <ndevos> post-factum: no, but we'll break users' installations on update, and they will complain, LOUDLY
12:38:16 <kkeithley> 3.3 = 2012-05-30,  3.4 = 2013-07-12,  3.5 = 2014-04-17, 3.6 = 2014-10-13, 3.7 = 2015-05-14, 3.8 = 2016-05-xx; 3.3->3.4: 14 mos, 3.4->3.5: 9 mos, 3.5->3.6: 6 mos, 3.6->3.7: 7 mos, 3.7->3.8: 12 mos.
12:38:38 <kkeithley> Off hand I'd say if we really stuck to six month releases we'd be in much better shape
12:38:46 <ndevos> kkeithley: yeah, we really have to force doing 6 month releases
12:38:51 <post-factum> ndevos: if you break it once in 1.5 years but do it HARD, they will complain even LOUDLY
12:39:39 <ndevos> post-factum: sure, but when we do major updates that is expected, I just dont like to force users to update too often
12:39:47 <rastar> ok, we are discussing two things, release period and also number of stable releases.
12:39:59 <post-factum> ndevos: but that fear keeps users from updating
12:40:10 <rastar> if release period is set to 6 months as ndevos and kkeithley suggest, that would be 3 stable releases
12:40:41 <rastar> can we have some balancing between the two to have only 1 stable release at a time?
12:40:57 <ndevos> post-factum: maybe, but I think their fear is currently justified, we even broke minor updates in 3.7 several times - until we do that better, I dont think we should require major updates faster
12:41:33 <rastar> #chair ndevos
12:41:33 <zodbot> Current chairs: ndevos rastar
12:41:39 * ndevos \o/
12:41:50 <post-factum> ndevos: instead of coping with fear, why not just make it less but still permanent? you won't avoid breaking things anyway
12:41:53 <rastar> ndevos: would you please take over? I have asked to debug some issue
12:41:56 <rastar> *been
12:42:05 <ndevos> rastar: oh, thats why!
12:42:23 <rastar> yeah, sorry :(
12:42:34 <ndevos> np, ttyl!
12:43:35 <post-factum> "release often, release early"
12:43:38 <pranithk1> ndevos: post-factum: kkeithley: so what do we do? How do we keep things stable yet give new stuff to people who want things
12:44:02 <ndevos> pranithk1: yes, I was thinking of calling your mid-term releases
12:44:10 <ndevos> "snapshot versions" or something
12:44:16 <kkeithley> Release Early. Release Often
12:44:29 <pranithk1> post-factum: kkeithley: what is often?
12:44:35 <ira> kkeithley++
12:44:36 <glusterbot> ira: kkeithley's karma is now 5
12:44:52 <post-factum> pranithk1: 2–3 months, like kernel ppl do
12:44:52 <kkeithley> Six months is what the community voted on at some point.
12:45:01 <ndevos> "release early & often" is all fine, but people still think their storage is different from other applications and want it to be very stable
12:45:09 <kkeithley> Kernel is four months.  And they have a lot more "release manager" types
12:45:27 <post-factum> kkeithley: no, kernel is ~62 days in average
12:45:32 <kkeithley> whatever
12:45:43 <ndevos> but the kernel also provides -stable releases, right?
12:46:03 <post-factum> ndevos: some are stable, some are stable and LTS
12:46:05 <jdarcy> Backporting burden is a huge part of this.  Some day, I hope we can get to a point where backports by the core team are very limited and "interested parties" (or consultants for same) do their own backports to older versions.
12:46:34 <ndevos> jdarcy: indeed, and backports should really only be for bugfixes, an not features
12:46:37 <post-factum> ndevos: i'd say we want LTS for storage to be stable
12:46:55 <pranithk1> ndevos: agree!
12:47:09 <kkeithley> we've been asked about doing an LTS by a couple people.  I haven't seen it gain much traction.
12:47:36 <post-factum> then, instead of dealing with 1 LTS you will deal with 3 stable branches
12:47:45 <post-factum> consider backporting efforts for doing that
12:48:14 <ndevos> the oldest stable branch would get backports to at most 1.5 year old code, I think that is doable
12:48:47 <ndevos> but, we're taking quite a chunk of time from the meeting
12:48:54 <kkeithley> I'd be happy to _start_ by getting regular releases every six months.  Once we can achieve that, then, IMO, we can consider LTS or longer term -stable.
12:49:01 <kkeithley> As it is now, 3.7.x is LTS.
12:49:06 <kkeithley> de facto LTS
12:49:12 <ndevos> pranithk1: could you summarize the requirements and email that around?
12:49:19 <ira> How does the kernel pick its stable releases that they maintain long term?
12:49:25 <aravindavk> ndevos: difficult to backport if conflicts(if dependent patch not backported or dependent patch is feature)
12:49:26 <pranithk1> ndevos: In which mailing list? devel?
12:49:37 <post-factum> ira: one in two years, afaik
12:49:48 <ndevos> aravindavk: we will have many less backports if we do not backport features :)
12:49:56 <ira> post-factum: Actually, their downstreams do it for them.
12:49:58 <ndevos> pranithk1: yeah, -devel would be good
12:50:23 <post-factum> ira: lets do not consider ubuntu ppl
12:50:29 <ndevos> #action pranithk1 sends out a summary of release requirements, with some ideas
12:50:30 <post-factum> ira: lts is done by Greg
12:50:52 <ndevos> #topic amye to check on some blog posts being distorted on blog.gluster.org, josferna's post in particular
12:51:09 <ndevos> does anyone know if that was done?
12:51:10 <aravindavk> ndevos: problem is when feature changes common code
12:51:56 <ndevos> aravindavk: sure, in that case it most likely is not a backport, but a bugfix only applicable for the older version
12:52:06 <ndevos> #action amye to check on some blog posts being distorted on blog.gluster.org, josferna's post in particular
12:52:26 <ndevos> #topic hagarth will start a discussion on his release-management strategy
12:52:32 <ndevos> hmm, isnt that the same?
12:52:50 <jdarcy> ndevos: I highly doubt it.  Too many other priorities.
12:53:04 <ndevos> ok
12:53:11 <ndevos> #action hagarth will start a discussion on his release-management strategy
12:53:17 <ndevos> #topic kshlm to check with reported of 3.6 leaks on backport need
12:53:26 <ndevos> but kshlm isnt here...
12:53:33 <ndevos> #action kshlm to check with reported of 3.6 leaks on backport need
12:53:45 <ndevos> #topic GlusterFS 3.7
12:53:53 <ndevos> Tracker: https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.7.12
12:53:55 <glusterbot> Bug glusterfs: could not be retrieved: InvalidBugId
12:54:23 <ndevos> 3.7.12 should have been released around the 30th of last month...
12:54:39 <ndevos> the agenda mentions that there is a need for someone to do that
12:54:56 <ndevos> did anyone volunteer to release 3.7.12?
12:55:42 <ndevos> if there is nobody, I highly doubt that doing more releases is something that we can manage :-/
12:56:04 <post-factum> twss ;)
12:56:12 <ndevos> #help 3.7.12 has not been released yet, still needs a volunteer to take this on
12:56:34 <ndevos> #topic GlusterFS 3.6
12:56:44 <ndevos> raghu isnt here...
12:56:57 <ndevos> tracker: https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.6.10
12:56:57 <glusterbot> Bug glusterfs: could not be retrieved: InvalidBugId
12:57:25 <ndevos> #help 3.6.10 can use a volunteer to help raghu with doing the release
12:57:34 <ndevos> #topic GlusterFS 3.5
12:57:54 <ndevos> there are no updates for 3.5, nobody asked for bugfixes, nobody sent patches
12:57:58 <jdarcy> Move that we drop 3.5 from the weekly reporting.
12:58:15 <ndevos> we should, once 3.8 is released
12:58:24 <ndevos> I'll maintain 3.5 until that is done
12:58:35 <atinm> ndevos, shouldn't we retire 3.5 once the first 3.8 release is out?
12:58:48 <ndevos> atinm: yes, that is the plan
12:59:05 <atinm> ndevos, ok
12:59:26 <ndevos> #info GlusterFS 3.5 will be retired when the first 3.8 release is a fact
12:59:32 <ndevos> #topic GlusterFS 3.8
12:59:40 <kkeithley> T-minus 27 days until 3.8
12:59:48 <kkeithley> or sooner
13:00:03 <ndevos> #info GlusterFS 3.8 has been branched, see http://www.gluster.org/pipermail/gluster-devel/2016-May/049330.html
13:00:25 <ndevos> #info GlusterFS 3.8 Release Candidate 1 is to be expected later this week
13:01:05 <ndevos> still needs updates to the roadmap, MAINTAINERS file in the sources and user facing release-notes and docs updates
13:01:17 <ndevos> and, of course, more testing!
13:01:36 <ndevos> no time for questions, we're moving to the next topic
13:01:43 <ndevos> questions can be sent by email though :)
13:01:48 <ndevos> #topic Gluster 4.0
13:02:01 <atinm> jdarcy's email pretty much summarizes it
13:02:17 <ndevos> link?
13:02:20 <jdarcy> Nothing to add here.
13:02:42 <atinm> http://www.gluster.org/pipermail/gluster-devel/2016-May/049375.html
13:02:43 <jdarcy> http://www.gluster.org/pipermail/gluster-devel/2016-May/049367.html
13:02:54 <ndevos> thanks!
13:03:11 <atinm> huh! Why are the links different?
13:03:19 <ndevos> lol
13:03:20 <ndevos> #topic Announcements / Reminders
13:03:27 <ndevos> If you're attending any event/conference please add the event and yourselves to Gluster attendance of events: https://public.pad.fsfe.org/p/gluster-events
13:03:30 <jdarcy> atinm: Yours is to a second message further down-thread.
13:03:30 <ndevos> Put (even minor) interesting topics on https://public.pad.fsfe.org/p/gluster-weekly-news
13:03:33 <ndevos> Use the following etherpad for backport requests  https://public.pad.fsfe.org/p/gluster-backport-requests
13:03:47 <atinm> Ahh right
13:03:48 <ndevos> #topic Open Floor
13:04:00 <ndevos> anything that needs urgent discussion?
13:04:06 <atinm> yes
13:04:16 <ndevos> and can be handled in under a minute?
13:04:19 <overclk> nothing urgent - I put it up but can be followed over email
13:04:32 <atinm> We are thinking of coming up with a 4.0 demo (a sort of show and tell hang out session) for 4.0 features
13:05:50 <atinm> So question here is can we utilize one such community meeting monthly and have those sessions or it has to be scheduled separately??
13:05:53 <ndevos> overclk: yeah, your topic should be done by email in any case :)
13:06:25 <atinm> this is just to showcase how 4.0 is progressing and getting valuable feedback from the community
13:06:40 <ndevos> atinm: these meetings tend to be pretty active, I do not think it would be good to skip them on regular basis
13:07:04 <atinm> so you vote for a different schedule, ndevos ?
13:07:19 <ndevos> and we want to see all maintainers join these meetings, lets try not to confure them too much with alternating schedules
13:07:35 <ndevos> atinm: yeah, I would like to see a different slot for hangouts
13:07:52 <atinm> Probably for the sake of time, I'll initiate an email and seek opinion on that?
13:07:57 <ndevos> yes please :)
13:08:03 <atinm> ndevos, ok
13:08:19 <ndevos> #action overclk will send an email about maintenance of teh changelog xlator
13:08:42 <ndevos> #action atinm will send an email about scheduling hangout sessions for 4.0 features
13:09:16 <ndevos> so, even with the side-tracking of release planning, we managed to keep it under 10 minutes overtime
13:09:20 <ndevos> #endmeeting