15:00:21 <kshlm> #startmeeting Community Meeting 2017-03-01
15:00:21 <zodbot> Meeting started Wed Mar  1 15:00:21 2017 UTC.  The chair is kshlm. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:21 <zodbot> The meeting name has been set to 'community_meeting_2017-03-01'
15:00:30 <kshlm> #topic Roll call
15:00:40 * shyam is here
15:00:41 <kshlm> Welcome to the meeting everyone!
15:00:59 <kshlm> I'll wait for 5 more minutes for more people to show up.
15:01:04 <kshlm> Hey shyam!
15:01:35 * vbellur is here
15:02:24 <kshlm> Hey vbellur!
15:02:46 <kshlm> Aren't you guys on the west coast this week?
15:02:53 <shyam> Not me
15:02:56 <shyam> :)
15:03:04 <kshlm> Cool!
15:03:30 <kshlm> I thought the meeting would be empty this week.
15:03:37 <vbellur> not me either :)
15:04:30 <kshlm> We have atleast 3 attendees.
15:04:32 <kshlm> That's good.
15:04:51 <nigelb> I'm lurking
15:04:59 <nigelb> (for the most part)
15:05:10 <vbellur> hey nigelb!
15:05:15 <nigelb> Hello :)
15:05:33 <kshlm> So it's just the 4 of us then.
15:05:37 <kshlm> Let's start.
15:05:44 <kshlm> shyam, has a topic up.
15:06:03 <kshlm> #topic Discuss backport tracking via gerrit Change-ID
15:06:34 <shyam> ok, here goes, so our backport guideline document talks about using the same Change-ID as the one in master: http://gluster.readthedocs.io/en/latest/Developer-guide/Backport-Guidelines/
15:06:45 <shyam> But, we do not enforce this (more on this later)
15:07:13 <shyam> The issue is, how can we ensure things are backported across releases, and are not missed in later releases
15:07:42 <shyam> For example, post branching a release (say 3.10) a fix is made in master and backported to 3.8
15:07:49 <shyam> but,not 3.10, we need this audited
15:08:03 <nigelb> I tried to do this about 6 months ago and hit the same wall.
15:08:13 <nigelb> there's no "primary key" so to speak.
15:08:22 <shyam> Current schemes for doing this are using 'git cherry' and then manually wading through the list, to looking at gerrit date sorted order, I would like it automated
15:08:42 <shyam> Yup, nigelb agreed, the primary key, looks like the Change-ID (as long as we use gerrit)
15:09:12 <shyam> Hence, back to backporting guidelines doucment, why did we write that we want the change-ID retained? Why are we not enforcing it?
15:09:32 <vbellur> shyam: ndevos might be able to help with an answer about the why
15:09:47 <nigelb> Why we did it, precisely why you want to enforce it.
15:09:51 <kshlm> FWIW, when I did backports, I used to change the change-ids.
15:09:57 <shyam> Former, question I have the above answer now, i.e audit what went into which branch
15:09:57 <nigelb> Because it was meant to be the primary key.
15:10:09 <shyam> Ah! ok then *should* we enforce it?
15:10:27 <vbellur> enforce and track better are the reasons I think
15:10:31 <kshlm> I don't know when we changed to the current guidelines.
15:10:35 <shyam> kshlm: I have noticed that among other submitters as well, hence the question :)
15:10:39 <vbellur> I am in favor of doing that if it helps
15:10:45 <nigelb> I've noticed that same people do it different ways.
15:10:51 <nigelb> So I think it has something to do with changes to the patch?
15:11:18 <nigelb> i.e. if it doesn't backport cleanly and you have to do it on the command-line to get the conflicts eased.
15:11:25 <nigelb> kshlm: ^^ Is that an accurate guess?
15:11:39 <kshlm> nigelb, Not really. I did it because I thought gerrit needed unique change-ids to track every review.
15:11:53 <nigelb> It does. But it's actually unique to branch.
15:11:58 <kshlm> But gerrit uses a combination of change-id+branch+repo to track a change.
15:12:03 <shyam> In a branch it needs unique change-ID, not ... there nigelb covered it :)
15:12:16 <kshlm> Now I know better.
15:12:47 <nigelb> Planning to enforce is good, but I can't think of an easy way to enforce this.
15:12:57 <shyam> Also, our rfc.sh is good enough to recognize that there is a Change-ID and not assign one, so as long as we retain the change-ID we can automate the whine
15:13:00 <kshlm> But even if you do need to change/modify the patch to make it apply when backporting, we can keep the id same.
15:13:13 <shyam> kshlm: yes
15:13:16 <nigelb> how does gerrit know a change is a backport?
15:13:30 <shyam> nigelb: :) no idea (yet)
15:13:41 <kshlm> Gerrit doesn't.
15:13:50 <shyam> But let's get to this, so it is a good idea to have this as the process, and enforce it? Yes?
15:13:53 <nigelb> I don't think all changes that land in non-master branches have to land in master.
15:14:03 <nigelb> so, there's no easy way to enforce.
15:14:20 <nigelb> But would it help if we made a Jenkins job that suggested?
15:14:36 <nigelb> not voting, but adding a comment if the change ID could not be found in master
15:14:52 <nigelb> "This change was not found in master. You may want to correct your changeID" or some such.
15:15:08 <shyam> yes, that is a good trigger for people who merge changes as well
15:15:12 <nigelb> If that helps, I'm happy to add a Jenkins job for that.
15:15:20 <nigelb> I'll take an action for it.
15:15:33 <nigelb> (if agree that's a good idea)
15:15:38 <kshlm> This would be for just done just for the release branches right?
15:15:42 <nigelb> yes.
15:15:44 <shyam> yes
15:15:52 <nigelb> If we want to send out an email to gluster-devel to discuss before
15:15:54 <nigelb> that's also good.
15:15:55 <shyam> I vote a "yes" but then again...
15:16:01 <nigelb> There's only 4 of us
15:16:08 <shyam> I bring it here, so maybe it does not count...
15:16:08 <nigelb> clearly not qourum :)
15:16:31 <shyam> Yup, agree, I need to do that anyway, but this helped, as I do not see any disagreement on this
15:16:39 <shyam> till now i.e
15:16:39 * amye is here
15:16:41 <kshlm> We can bring it up on the mailing list as well.
15:16:46 <kshlm> Hey amye!
15:16:48 <amye> but not quorum worthy on this topic :)
15:17:10 <kshlm> But since this change doesn't actually block anything, we could just go ahead.
15:17:23 <vbellur> let us change and see if folks complain ;)
15:17:24 <nigelb> yeah, it will just create some extra messages on release branches.
15:17:30 <nigelb> no failed job or anything.
15:17:58 <shyam> ok, so I see actions as, notify devel -> hear any feedback -> implement or not based on feedback (bug on infra for Nigel to add the Jenkins job, unless we hear/get a better idea), fine?
15:18:14 <nigelb> sounds good.
15:18:25 <kshlm> All of this on nigelb?
15:18:35 <nigelb> I'm only doing implementing.
15:18:38 <shyam> First couple are on me I would assume...
15:18:42 <nigelb> I'm guessin shyam is doing feedback?
15:18:44 <kshlm> Cool.
15:19:12 <shyam> Done with the topic for now...
15:19:14 <kshlm> #action shyam to notify devel list about the backport whine job and gather feedback
15:19:33 <kshlm> #action nigelb will implement the backports whine job after feedback is obtained
15:19:53 <kshlm> shyam, Cool!
15:19:59 <kshlm> That's the only topic we had.
15:20:09 <kshlm> Anything else we want to discuss?
15:20:48 <nigelb> Just a reminder about the infra outage this month.
15:20:53 <nigelb> I've added a note in the meeting notes.
15:20:56 * atinm joins late
15:21:19 <vbellur> nigelb: what is your guesstimate on the outage duration?
15:21:28 <kshlm> nigelb, Yup. I'll call that out in the minutes mail.
15:21:34 <nigelb> vbellur: At least 8 to 9 hours.
15:22:06 <nigelb> It's happening in EST working hours
15:22:35 <kshlm> So it's basically no impact for us here in India
15:22:39 <kshlm> (if all goes well)
15:22:45 <nigelb> assuming you don't work late
15:22:48 <vbellur> nigelb: ok..
15:22:49 <nigelb> or start really early :)
15:23:10 <vbellur> kshlm: nigelb also has suggested nice alternatives to do when not pushing patches to gerrit :)
15:23:36 <nigelb> considering all the work misc has put into Coverity fixes, I like the idea of sending him a cake :D
15:23:58 <vbellur> I refreshed gerrit sometime last week and only saw Misc in there :)
15:24:07 <kshlm> vbellur, yeah, but these days I'm not sending out a lot of patches on gerrit.
15:24:18 <kshlm> So I should be fine.
15:25:22 <vbellur> kshlm: for the rest who send out patches, that list is pretty good
15:25:47 <shyam> Considering 3.11 focus on testing improvements, that list is gold ;)
15:26:31 <kshlm> shyam, On the topic of 3.11, we should do a formal announcement of the testing focus.
15:26:49 <shyam> Yes, currently the announce is just 3.11 etc
15:27:08 <shyam> I am going to ask for volunteers to lead the testing focus for 3.11
15:27:24 <kshlm> Also, are you continuing on to maintain 3.11?
15:27:28 <shyam> and, let them run with the focus (at least that is the thought)
15:28:05 <shyam> kshlm: yes, at present, I would like to finish the github streamlining with this (and possibly the next) release
15:28:11 <shyam> But, additional hands welcome
15:28:29 <kshlm> Cool. I'll help out where ever I can.
15:28:37 <kshlm> I don't have 3.7 anymore.
15:28:54 <kshlm> But, I do want to focus more of my time on GD2.
15:29:01 <shyam> Sure thanks, do you want me to add you officially (i,e in the notes, communitcations) as part of the release team?
15:29:05 <kshlm> I'd like to get a preview release out with 3.11.
15:29:13 <vbellur> kshlm: that would be fantastic!
15:29:19 <nigelb> re: testing focus, I'll be among the 3 gatekeepers for glusto tests in terms of code review.
15:29:39 <vbellur> nigelb: cool
15:31:12 <kshlm> Just a quick question. Can we use glusto for GD2 as well?
15:31:15 <kshlm> I mean right now.
15:31:52 <nigelb> Does the interface from gluster-cli remain the same?
15:31:56 <kshlm> We're planning on improving out tests, so if we could start writing them using glusto from the start it would be nice.
15:32:04 <kshlm> nigelb, We don't have a cli yet.
15:32:18 <nigelb> Let's talk tomororw morning.
15:32:26 <nigelb> It may or may not fit depending on what you want to do.
15:32:30 <kshlm> We have a rest api, but since glusto is python, it should be okay.
15:32:47 <kshlm> Cool.
15:32:59 <kshlm> I'll ping you tomorrow (unless I forget).
15:33:06 <nigelb> I'll make a note
15:34:13 <kshlm> On another note, I had a meeting with several maintainers in Bangalore earlier today about backlog generation.
15:35:08 <kshlm> We should expect some backlogs before next weeks maintainers meeting.
15:35:18 <vbellur> kshlm: awesome! thank you for doing that
15:36:12 <kshlm> One thing I came to know is that a lot of them weren't tracking the maintainers list.
15:37:08 <kshlm> It was because it was only for people who are officially called maintainers in our MAINTAINERS file, or the people maintaing releases.
15:37:48 <kshlm> Most of the people, even thought they don't have merge rights like official maintainers, basically maintain their own components.
15:38:41 <vbellur> kshlm: which components are these?
15:38:46 <kshlm> We need try and get them and included.
15:39:04 <amye> kshlm, inviting them to the mailing list explicitly?
15:39:31 <kshlm> I asked them to join the list to keep themselves updated on whats happening.
15:39:50 <nigelb> This deserves a discussion as part of Maintainers 2.0 that Amye was working on.
15:39:56 <vbellur> kshlm: we plan to revise maintainers post 3.11 (maintainers as ones listed in MAINTAINERS)
15:39:58 <kshlm> nigelb, Yes.
15:39:59 <amye> nigelb, yes, yes it it does.
15:40:07 <nigelb> (I rememeber a maintainers meeting from a while ago)
15:40:14 <vbellur> as part of 2.0 revamp
15:40:23 <kshlm> The components are mostly those whose current maintainers maintain a lot of things.
15:40:34 <kshlm> Or some small parts that grew big.
15:41:04 <amye> I think that we can revise what it means to be a maintainer, write it down, try it on for 3.11 and finalize it for .. 4.0?
15:41:45 <kshlm> amye, Yes please.
15:43:03 <amye> Ok, I'm thinking of where we've gotten stuck on this. Is it because we didn't have agreement that maintainers as a role needed to be expanded?
15:43:31 <amye> I can certainly put a draft out to gluster-devel + maintainers
15:43:33 <vbellur> amye: we thought there was general agreement about the proposal
15:43:51 <amye> vbellur, ok, so more about specifics then?
15:44:00 <vbellur> amye: yes, we need to carve that out
15:44:31 <amye> 'you must be this tall to ride' for maintainers checklist? (I'm thinking out loud over my first cup of coffee)
15:45:47 <nigelb> Is it too late to say that we're packing too much into "maintainers"? :)
15:45:51 <amye> It's abundantly clear to me (and this is just my opinion), that we need more maintainers. So let's make it more coherent. I can take the action item to expand this to gluster-devel today, and we'll move forward.
15:45:55 <amye> Not at all, nigelb.
15:46:10 <nigelb> There doesn't seem to be a baby step.
15:46:16 <vbellur> amye: happy to work on the draft with you
15:46:21 <nigelb> Sort of "in-training" maintainer
15:46:31 <amye> vbellur, ack
15:47:30 <amye> I'm reluctant to add yet another process, but yes, a way to be a maintainer without being 'the only one'. Same problem as we have with packaging, yes?
15:47:36 <amye> There's no way to be 'a little packaging'
15:47:45 <nigelb> Yep. That.
15:48:26 <nigelb> For release manager we do have a baby step.
15:48:34 <nigelb> You can help someone release, with one person taking lead.
15:48:41 <nigelb> That's what'd be reat for maintainers too.
15:48:43 <nigelb> *great
15:48:47 <amye> Ok, so that's a place to start.
15:49:01 <amye> 'Lead with two - three assisting'
15:49:15 <nigelb> Otherwise, we're going to end up with burn out :(
15:49:29 <amye> Which is where we are now. :)
15:49:40 <amye> Might as well start to fix it.
15:50:53 <kshlm> This will be a good things.
15:51:31 * sankarshan waves ...
15:51:55 <kshlm> I had a chat with pranith today about his reduced upstream participation recently.
15:51:56 <amye> AI: Amye to work on revised maintainers draft with vbellur to get out for next maintainer's meeting. We'll approve it 'formally' there, see how it works for 3.11.
15:52:13 <amye> kshlm, hey, you're right, I haven't seen Pranith in an age!
15:52:27 <kshlm> And thing that stood out was that he was just too overloaded managing lots of things.
15:53:00 <amye> So a way to be able to hand off projects to other people might have the effect of getting more done?
15:53:12 <kshlm> Yup.
15:53:17 <amye> Interesting.
15:53:34 <kshlm> He said he'd start a discussion on the maintainers list.
15:53:42 <kshlm> (if he ever gets the time).
15:53:43 <amye> I think we'd need to put a time window on transitioning projects to other people, like over three weeks, otherwise it'd be chaos
15:53:59 <amye> Ok, I'll watch for that conversation.
15:54:54 <kshlm> #action amye  to work on revised maintainers draft with vbellur to get out for next maintainer's meeting. We'll approve it 'formally' there, see how it works for 3.11.
15:55:06 <amye> thank you, kshlm
15:55:12 <kshlm> :)
15:55:50 <kshlm> Are we done with this discussion for now? I'll end the meeting if so.
15:56:20 <amye> I believe so.
15:56:29 <vbellur> thank you kshlm!
15:56:31 <kshlm> Cool.
15:56:45 <kshlm> Thanks for coming in everyone.
15:57:04 <kshlm> I'll send out the meeting email later tomorrow morning.
15:57:13 <kshlm> And I'll be hosting the next meeting myself.
15:57:20 <amye> excellent.
15:57:28 <kshlm> See you all on the 15th.
15:57:32 <kshlm> #endmeeting