15:00:01 <smcginnis> #startmeeting releaseteam
15:00:02 <openstack> Meeting started Fri Mar 23 15:00:01 2018 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:06 <openstack> The meeting name has been set to 'releaseteam'
15:00:08 <ttx> o/
15:00:08 <smcginnis> Ping list: dhellmann, dims, fungi, tonyb, lbragstad, ttx, armstrong
15:00:40 <dhellmann> o/
15:00:41 <armstrong> Hello
15:00:43 <smcginnis> #link https://etherpad.openstack.org/p/rocky-relmgt-tracking Agenda - R-23
15:00:51 <ttx> annabelleB: ping too
15:01:00 <smcginnis> Made it back safe from Dublin armstrong? :)
15:01:06 <annabelleB> o/
15:01:20 <smcginnis> annabelleB: Want to add your nick to... nevermind. :)
15:01:27 <armstrong> @smcginnis: Yes back in Montreal
15:02:22 <smcginnis> OK, looks like the gangs all here.
15:02:31 * lbragstad lingers
15:02:36 <smcginnis> #topic Next steps for on-boarding
15:02:42 <smcginnis> Morning lbragstad
15:02:52 <smcginnis> ttx: Do you want to take this?
15:03:06 <ttx> OK, so I posted a basic CONTRIBUTING.rst with stages of involvement
15:03:12 <ttx> #link http://git.openstack.org/cgit/openstack/releases/tree/CONTRIBUTING.rst
15:03:19 <smcginnis> armstrong: You may be interested in taking a look at that if you haven't seen it yet. ^
15:03:26 <smcginnis> annabelleB: And you too of course.
15:03:41 <ttx> By default all newcomers are in stage 0, they can do code reviews on openstack/releases
15:03:43 <armstrong> @smcginnis: ok I will
15:04:01 <ttx> Once familiar with the review rules there, you can move to stage 1
15:04:20 <ttx> which is about approving release requests
15:04:35 <ttx> to achieve that, you must be successful in stage 0 and learn a few more tricks
15:04:51 <dhellmann> annabelleB and I walked through a review together wednesday. I can turn the notes from that into more detailed review guidelines.
15:04:56 <ttx> I've been trying to document those 1st two stages but it's probably still incomplete
15:05:04 <ttx> right
15:05:48 <ttx> Best way to try that ladder while doc is still incomplete is to walk through it with a reviewbuddy
15:06:29 <smcginnis> And make notes and propose updates to help flesh out that guide better.
15:06:34 <ttx> Stage 1 is more about understanding what happens when you press the button, and learn when not to press the button
15:07:04 <smcginnis> When not to press is usually the trickier one.
15:07:06 <armstrong> Sounds good to me
15:07:15 <dhellmann> do we want those details in the contributing doc? or a separate review-guidelines file?
15:07:26 <ttx> So for the moment feel free to do some release reviews or ask questions on how to do them
15:07:28 <annabelleB> read through the release management docs and README last night—did find it helpful to read them side by side, but didn’t end up with a ton of “this needs to be clarified” questions
15:07:33 <smcginnis> I was thinking this doc could link to more deep-dive material.
15:07:54 <ttx> dhellmann: yeah, I would rather keep the CONTRIBUTING file simple
15:07:58 <dhellmann> makes sense
15:07:59 <smcginnis> annabelleB: Awesome!
15:08:04 <dhellmann> I'll start a new file
15:08:32 <smcginnis> I think (hope) this is something we can continually evolve.
15:08:54 <ttx> for example I think we should not go beyond the primer when it comes to explaining the release infra
15:09:31 <ttx> but I think understanding that it is two separate steps is important
15:09:44 <ttx> since that's not very intuitive
15:09:56 <dhellmann> ttx, are you worried about writing up details that are likely to change? or making it seem too complicated?
15:09:56 <smcginnis> ttx: I do like how this ended up. Nice work.
15:10:12 <ttx> dhellmann: too complicated I guess...
15:10:17 <dhellmann> ok
15:10:36 <ttx> dhellmann: although a separate file with review guidelines might end up being overall more complex than inline
15:10:51 <ttx> the line is really between tutorial and reference
15:10:51 <fungi> but also, duplicating documentation inevitably leads to confusing divergence
15:10:54 <dhellmann> let's see what I actually come up with and we can talk about it in the review
15:11:02 <smcginnis> I do like being able to quickly see the big picture, then being able to get into specific details.
15:11:08 <fungi> so linking to somewhere else things are explained in detail reduces the chances of that
15:11:21 <ttx> The CONTRIBUTING file is a tutorial with steps, pointing to reference material
15:11:33 <dhellmann> I think we have some guidelines in the readme already, so I'll move those and add to it and then refer to the new file from both places
15:11:39 <fungi> seems like a fine scope for that document
15:11:46 <ttx> Like we would point to PROCESS rather than duplicating info
15:11:50 <dhellmann> sure
15:11:55 <ttx> review guidelines are a bit in the grey area
15:11:56 <smcginnis> dhellmann: Or refer to the CONTRIBUTING doc if it makes sense based on context.
15:12:09 <dhellmann> ok
15:12:24 <ttx> They could fit in the document, I just fear it will end up making a discouraging read
15:12:46 <ttx> so it depends how wordy you expect the result to be
15:13:25 <dhellmann> yeah, I have an hour's worth of irc logs to condense so let me see how that turns out
15:13:26 <ttx> that is all
15:14:23 <smcginnis> #topic Next steps on simplifying branch ACL process
15:14:40 <ttx> ohai!
15:14:45 <smcginnis> I think Tony's patch still needs to merge, right?
15:14:56 <ttx> Sure but we have the general idea
15:15:01 <smcginnis> So we've passed governance allowing it, but stable has not technically changed yet.
15:15:06 <ttx> (the EM definition is merged)
15:15:16 <ttx> Issue is...
15:15:36 <ttx> quoting the plan we came up with in Dublin...
15:15:39 <ttx> "makes a lot of sense if we're going to have per-series LTS ownership groups anyway"
15:15:54 <smcginnis> And now we are not.
15:15:54 <ttx> We already know that EM as defined  is not really encouraging separate groups
15:16:14 <ttx> Furthermore... Patching ACLs every cycle to add a per-project per-branch group might be overkill
15:16:36 <ttx> So I'm wondering if we are not prematurely optimizing
15:16:52 <ttx> We could just give $PROJECT-stable-maint control over stable/* once and for all, include Release Managers there, and let projects get more specific if they really want to
15:17:44 <smcginnis> How is that different than our process so far? More power to the teams rather that the "stable" team for controlling those rights?
15:17:55 <ttx> So, currently...
15:18:28 <ttx> Every cycle we create a specific ACL for the stable/$under-development to-be-created branch
15:18:38 <ttx> That ACL points to a magic group
15:18:45 <ttx> which initially contains release managers
15:19:12 <ttx> then when we release, we change the content of the magic group to point to $project-stable-maint
15:19:20 <ttx> and then we remove the specific ACL
15:19:39 <ttx> The difference is that stable-maint doesn't have control on the pre-release branch
15:19:46 <smcginnis> So you're proposing we skip the magic ACL step?
15:19:56 <smcginnis> And just go to the final stable state.
15:19:59 <ttx> I'm proposing to skip all steps
15:20:17 <fungi> the reduction in acl churn would be marvellous
15:20:28 <smcginnis> That makes sense to me and I like how it would simlify things.
15:20:32 <ttx> Have stable/* pointing to $project-stable-maint and never change that
15:20:36 <smcginnis> And even simplify them.
15:20:58 <smcginnis> Anyone have concerns with that approach?
15:21:16 <ttx> Basically we are trusting $project-stable-maint to not do anythign crazy with pre-release branch, and they are trusting us to not do anythign crazy with post-release stable branches
15:22:00 <ttx> This complex process was designed for a time when we expected very different people
15:22:09 <ttx> to handle pre-release and post-release
15:22:17 <smcginnis> Yeah, I don't think that is the reality today.
15:22:21 <ttx> In reality, those are the same people 99% of the time
15:22:32 <ttx> So it's a pretty costly process to handle those rare cases
15:22:39 <fungi> i thnik trusting people for a couple weeks is better than complex process to work around a lack of trust
15:22:43 <ttx> furthermore we are not preventing those rare cases to be specified
15:22:56 <ttx> IF you really want to have complex ACLs you still can
15:23:08 <ttx> But that's a project choice, and not part of release process
15:23:27 <smcginnis> fungi: ++
15:23:33 <dhellmann> I like a process change that means we just stop doing things.
15:23:50 * fungi would love to stop doing lots more things! ;)
15:23:55 <smcginnis> Hah, yep. That's a nice direction.
15:24:18 <ttx> I think we already have the required rights, too. Like release managers is in stable-maint-core which is in every stable-maint team
15:24:36 <ttx> so the "they are trusting us to not do anythign crazy with post-release stable branches" part is probably already a reality
15:24:43 * ttx checks
15:24:46 <fungi> those acl changes have also been a time-sensitive step in the past, and the people who are expected to review them are basically looking at thousands of lines of almost identical machine-generated changes
15:25:10 <smcginnis> So it seems we are all in agreement. Just update the PROCESS doc? Or should we start a ML thread first and see if there are any concerns.
15:25:14 <fungi> which has not been a great use of their time
15:25:16 <ttx> yes, we are trusted already
15:25:39 <dhellmann> so we need to communicate the change to the other folks and then update our process document
15:25:48 <ttx> OK, I can handle that
15:26:00 <smcginnis> ttx: Thanks
15:26:32 <smcginnis> #action ttx to write an email about dropping red tape
15:27:03 <smcginnis> #info Plan is to not have interim pre-release ACLs and go right to stable ACL
15:27:36 <smcginnis> Anything else on this topic?
15:27:44 <smcginnis> And any other topics? Nothing more on the agenda.
15:27:53 <ttx> Also 'm looking forward not having to explain that ACL dance ever again
15:28:15 <smcginnis> :)
15:28:19 <dhellmann> indeed
15:28:35 <smcginnis> #topic Open discussion
15:29:21 <dhellmann> I've been making some progress on the change to stop syncing requirements
15:29:22 <ttx> smcginnis, dhellmann: so are you coming to Copenhagen ? annabelleB and I will be there
15:29:31 <dhellmann> reviews appreciated
15:29:32 <dhellmann> #link https://review.openstack.org/#/q/topic:requirements-stop-syncing+(status:open+OR+status:merged)
15:29:40 <smcginnis> ttx: Yes, I did get final approval.
15:29:41 <dhellmann> I need to book that trip, but I have approval
15:29:52 <ttx> wow, release team almost complete
15:29:54 <smcginnis> All booked other than actual conference registration.
15:30:07 <ttx> oh, I should probably book that conference ticket
15:31:14 <armstrong> @ttx which conference?
15:31:27 * ttx wonders if he qualifies for Individual ticket, since he works for non-rofit
15:31:30 <ttx> +p
15:31:31 <smcginnis> dhellmann: I'm hoping to review some more of those later today.
15:31:36 <ttx> armstrong: KubeCon EU
15:31:46 <armstrong> Oh ok
15:32:09 <armstrong> Is the release team also involved with that?
15:32:58 <dhellmann> armstrong : we work closely with the requirements team, so not directly but sort of
15:33:13 <smcginnis> Just from a cross open source collaboration perspective.
15:33:13 <dhellmann> oh, or do you mean kubecon?
15:33:29 <armstrong> Ok! got It
15:33:33 <dhellmann> I think I mixed up 2 conversations there
15:33:51 <ttx> it happens that release management and community outreach people are a close match
15:33:58 <smcginnis> https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/
15:34:09 <armstrong> Yes, I was asking about the kubecon
15:34:45 <smcginnis> Nothing really to do with OpenStack other than being able to talk about sharing lessons learned and building good community connections.
15:36:24 <smcginnis> OK, anything else for today? Or should we call it a wrap?
15:36:34 <armstrong> @smcginnis: sounds good
15:37:11 <smcginnis> armstrong: If you're interested in that kind of thing but can't attend, I think ttx wrote up some nice summaries of discussions from the last time.
15:38:34 <armstrong> Sure Am
15:38:44 <armstrong> sure I am interested
15:39:25 <smcginnis> OK, everyone else has gotten quiet, so I'll take that as a sign. :)
15:39:28 <smcginnis> Thanks everyone!
15:39:33 <dhellmann> o/
15:39:33 <ttx> thx smcginnis
15:39:34 <annabelleB> thank you!!
15:39:35 <dhellmann> thx
15:39:37 <smcginnis> #endmeeting