14:00:53 <ttx> #startmeeting releaseteam
14:00:54 <openstack> Meeting started Fri Nov  4 14:00:53 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:57 <openstack> The meeting name has been set to 'releaseteam'
14:01:07 <ttx> courtesy ping for dhellmann, dims, fungi, stevemar
14:01:51 <ttx> Welcome back from Barcelona! This is week R-16, our agenda on the etherpad as usual
14:02:07 <ttx> #link https://etherpad.openstack.org/p/ocata-relmgt-tracking
14:02:16 <dims> o/
14:02:28 <ttx> dhellmann should join us really soon now
14:02:35 <fungi> still has that new-cycle smell
14:02:57 <ttx> #topic move (some) tags from governance to releases
14:03:41 <ttx> We have a plan to move some of the release mechanics tags (which are really not a governance thing) out of the governance repository
14:04:07 <ttx> You can see details of that plan on https://etherpad.openstack.org/p/ocata-relmgt-plan
14:04:24 <ttx> line 137+
14:04:58 <ttx> The idea would be to move type:* and release:* tags out of the governance repo
14:05:35 <fungi> and the lack of comments implies it's in no way contentious
14:05:37 <ttx> We would duplicate the deliverable structure between both
14:06:06 <fungi> any reason to duplicate the structure rather than just having a flat list of deliverables?
14:06:15 <ttx> Now we are wondering who we need to engage with early on, and who would get broken by this
14:06:34 <dims> ttx : which repo would be the authoritative source? (which sync's to which)
14:06:53 <ttx> fungi: I think we still need the team-deliverable relationship on the release side
14:07:13 <ttx> but when I say "duplicate" it's actually not a centralized yaml file
14:07:29 <ttx> On one side you would have the governance projects.yaml file
14:07:33 <fungi> any reason not to just let the deliverable to team mapping stay in governance, and just keep the deliverables as a flat list in releases though?
14:07:50 <fungi> that reduces the risk of having them get out of sync
14:08:06 <ttx> On the other a bunch of cycle/deliverable.yaml files in the releases repo
14:08:32 <ttx> fungi: I think that is the plan
14:09:11 <ttx> we would just store the release model and type of deliverable in the openstack/releases yaml files instead of the governance projects.yaml
14:09:17 <ttx> (which would stay authoritative)
14:09:27 <sigmavirus> probably a silly question, as a new release liaison, how familiar should I be with all of this/
14:09:36 <fungi> oh, got it. when you said duplicate the structure i thought you mean including grouping deliverables by team in releases, which seems like a lookup we could do against governance as a single source of authority for that
14:09:59 <ttx> sigmavirus: It should not change much for liaisons. Of all things it might make changing deliverables content and types easier
14:10:16 <ttx> Now, what/who will that break
14:10:33 <ttx> The project navigator uses type: to filter what it should display
14:10:41 <ttx> (only shows type:service)
14:10:41 <fungi> sigmavirus: basically if you plan to add a deliverable or change the release model you'll now need to also edit a file in the releases repo adding an entry to the current cycle's yaml file
14:11:00 <ttx> It also displays the release model, although I'm not sure why
14:11:09 <fungi> ttx: likely "because it can"
14:11:15 <ttx> yes
14:11:43 <ttx> We might want to generate some compound mega-yaml file for them to consume rather than force them to walk down the openstack/releases directory tree
14:11:58 <dims> sigmavirus : if you keep up with the rst files in https://github.com/openstack/releases/ that should be good enough i think
14:12:15 <fungi> we could easily postprocess all of this in a ci job and publish it as structured data or even provide a lightweight lookup api
14:12:57 <fungi> if there's a concern that they really can't retrieve two files and do the equivalent of a join query
14:13:04 <ttx> Any other idea of what might get broken by this ?
14:13:31 <sigmavirus> dims: thanks :)
14:13:42 <dims> any of the scripts used for validating the tags may be affected?
14:14:04 <ttx> They should not really look into type:* or release:*
14:14:05 <fungi> none of the automation i maintain cares about deliverable types or release models, so none on the infra side afaik (except for jobs the release team is caring for that is)
14:14:11 <dims> right
14:14:31 <sigmavirus> fungi: thank you for explaining that in terms I can understand ;)
14:14:33 <ttx> OK, let's move on
14:14:51 <ttx> #topic moving release date to Feb 22
14:15:01 <ttx> Also known as "because Ocata wasn't too short already"
14:15:23 <ttx> This is done to facilitate downstream post-release work
14:15:40 <fungi> bar napkin math says ot's still only a 1% shrinkage in the number of business days for the cycle
14:15:50 <ttx> Releasing on Thursdays kind of pushed them into Saturdays work more often than not
14:16:25 <ttx> I checked with the PR team at the Foundation, they have no particular relationship with Thursdays
14:16:25 <dims> +1 to do this
14:16:46 <ttx> Actually Wednesdays might even be better for them (for the same downstream work reasons)
14:18:01 <ttx> OK, so this looks good, I expect dhellmann to close it when he has a chance
14:18:11 <ttx> next topic...
14:18:19 <ttx> #topic changing the library freeze date
14:18:41 <ttx> In BCN we discussed moving the non-client lib out 1 week to match the 3rd milestone on R-4
14:19:15 <ttx> that said, dhellmann noted that moving to R-4 would mean that we do not freeze the libraries before the requirements list, which means we might end up adding features to a library but not having them be consumable because we can't update the lower bounds of a requirement
14:20:01 <ttx> So should we stick to 2 deadlines ? Or move all libraries up to R-3?
14:20:43 <dims> ttx did we get any preference from tonyb ?
14:20:48 <ttx> dims: do you remember why we considered doing that ?
14:22:25 <ttx> I'm missing a bit of info there. Let's wait for dhellmann
14:22:25 <dims> ttx : guessing we saw folks needing a library update to fix a problem late in their 3rd milestone
14:23:35 <ttx> We already have client lib freeze and requirements freeze on the same date, so I don't understand why that would make features any more less consumable
14:24:10 <ttx> Let's move on ang get back to that later if dhellmann joins us
14:24:16 <dims> ack
14:24:20 <ttx> #topic Moving release meeting one UTC hour later starting next week (keep same US time)
14:24:56 <ttx> Since teh US joins Europe out of DST next week, we can adjust our team meeting time to place it at the same local day hour
14:25:25 <dims> +1 ttx
14:25:27 <sigmavirus> I'm -0 on that as a central US person
14:25:39 <ttx> I'm +0 on that since I'm a EU person
14:25:58 <sigmavirus> Mostly because work weird hours as it is, so an hour earlier/later doesn't affect me
14:26:15 <ttx> Basically without the change, the meeting would be at 9am Eastern instead of 10am eastern if we don't change anything
14:26:28 * dhellmann arrives late
14:26:32 <ttx> here he is
14:26:34 <fungi> yeah, maybe people on the west coast of the usa care about this
14:26:36 <ttx> #chair dhellmann
14:26:37 <openstack> Current chairs: dhellmann ttx
14:27:09 <ttx> dhellmann: currently discussing moving the meeting hour to 15:00utc starting next week
14:27:09 <fungi> on the other hand, there are no release team members in western north america at the moment
14:27:33 <dhellmann> iirc we've moved it in the past, haven't we?
14:27:42 <ttx> I think so yes
14:27:48 <ttx> I'll propose the change
14:27:58 <dhellmann> yeah, let's move it if the slot is open
14:28:01 <ttx> #action ttx to propose meeting time change for release meeting winter time
14:28:03 <fungi> i'm not personally keen on meetings that change utc time because it's atypical in our community, but it's not my meeting ;)
14:28:25 <dims> :)
14:28:38 <ttx> #topic changing the library freeze date
14:28:43 <ttx> back to previous topic
14:29:26 <dhellmann> I looked at what would happen if we moved the dates as we said in BCN
14:29:27 <ttx> dhellmann: I was wondering why moving non-client lib freeze at the same time as client-lib freeze would be a problem wrt. requirements
14:29:37 <dhellmann> well, the requirements freeze would be the same time then
14:29:49 <ttx> if it is a problem, we already have it for client lib, then
14:30:14 <dhellmann> the server projects are less likely to be consumers of features added to the client libs
14:30:26 <dhellmann> at least that's my assumption
14:31:26 <dhellmann> since I proposed this change, and now I'm undecided, is anyone else strongly in favor of one course or the other?
14:31:49 <dims> dhellmann : keep what we have :)
14:32:10 <ttx> let's keep
14:32:11 <dhellmann> I think I'm leaning in that direction now, too
14:32:12 <ttx> in doubt
14:32:17 <dhellmann> ok, I think that's agreement
14:32:25 <dhellmann> #agreed we will not try to change the library freeze dates for ocata
14:32:35 <ttx> #link https://review.openstack.org/393800 <-- meeting time change
14:33:00 <ttx> ok, next topic
14:33:04 <ttx> #topic Freezing Monasca releases until the license is sorted out
14:33:22 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106687.html
14:33:28 <dhellmann> the email thread pointed to some confusion about what license is actually being used
14:33:44 <ttx> I suspect it's a leftover file but better make sure of that, and quick
14:33:47 <dhellmann> rather than making things worse, it seemed like a good idea to freeze any releases until they sort it out
14:33:52 <dhellmann> right, I assume the same
14:33:53 <fungi> agreed
14:34:06 <dhellmann> in fact, maybe someone could go ahead and propose the patch to update the file
14:34:12 <ttx> which means, given how present Monasca folks are on IRC, reaching out aggressively to them
14:34:29 <ttx> review might be a good way to get them to pay attention, yes
14:34:29 <fungi> i'd _love_ it if someone from monasca would respond there. do they read the -dev ml?
14:34:37 <sigmavirus> fungi: that would be ideal
14:34:38 <dhellmann> fungi : their participation is spotty
14:34:43 <dims> right
14:35:07 <fungi> seems like at least the ptl would be paying attention to things tagged [monasca] on the ml
14:35:10 <dhellmann> #agreed freeze monasca releases until the license situation is straightened out
14:35:11 <ttx> in the meantime, I agree we shouold not release anything there until they clarified
14:35:11 <dims> oslo.messaging kafka is stuck on their feedback as well
14:35:39 <dhellmann> dims : that's good to know
14:35:54 <ttx> Great example of why sharing the same communication/principles/culture is essential
14:35:54 <dhellmann> we've had trouble reaching that team a few times now. it might be time to bring it to the tc's attention.
14:36:06 <ttx> because in those cases it hurts everyone
14:36:29 <dhellmann> that said, it is only the week after summit so I was going to give them until next week before having a larger response
14:36:53 <dims> To be specific they had an action item to get back to us on g-r being switched to newer python-kafka versions
14:37:36 <fungi> also, i'll admit, the place to raise that license question is _probably_ monasca's bug tracker
14:37:39 <ttx> If we don't have any response by next week TC meeting I might raise the topic of minimal participation to communication mediums as a reason for not be official anymore
14:37:46 <fungi> i'll copy cuhck's request to a bug report
14:37:51 <dhellmann> fungi : good point, a bug would be nice
14:37:52 <ttx> fungi: thx
14:38:02 <dhellmann> ttx: ++
14:38:15 <fungi> and i'll follow up to the ml thread with the url
14:38:22 <dhellmann> thanks
14:38:27 <dhellmann> I think that covers this topic?
14:38:37 <ttx> yes
14:38:54 <ttx> #topic New driverfixes branch type
14:39:13 <ttx> #link https://review.openstack.org/#/c/393451/
14:39:48 <dhellmann> I just wanted folks on the release team to be aware that this is a new branch type. smcginnis and I picked the name yesterday. So far only Cinder uses it, but if other teams want to do something similar we'd want the same name type
14:40:02 <ttx> Still not a big fan of having untested branches in our official repos, but meh
14:40:18 <dhellmann> basically, this is a branch created from stable/$series at a point close to when the stable branch goes dormant, to give vendors a central place to collaborate on long-lived driver support
14:40:26 <ttx> untested/$series would make it clearer
14:41:01 <dhellmann> yeah, we talked about untested/driverfixes/$series as the name but that felt different from the other patterns we have with just 2 levels in the name
14:41:24 <dhellmann> and I think the idea is that only changes to drivers would be allowed in the branch, so we wanted to highlight that
14:41:33 <ttx> also discourages them to collaborate on stable branches a bit
14:41:34 <smcginnis> ttx, dhellmann: Still time to change it I suppose. untested/mitaka would be OK with me, though I do like the descriptive name of driverfixes.
14:41:40 <smcginnis> dhellmann: +1
14:41:52 <ttx> smcginnis: yeah, untested only partially captures the idea
14:42:12 <dhellmann> ttx: I thought the opposite -- if they get used to collaborating on these branches, maybe they'll be encouraged to also work on the stable branches before the driverfixes branch is created
14:42:36 <ttx> who has +2 on driverfixes/*
14:42:38 <ttx> ?
14:42:44 <dhellmann> good question. smcginnis?
14:42:46 <ttx> some specific group ?
14:42:49 <smcginnis> ttx: Core team only for now.
14:42:59 <smcginnis> So for this instance, cinder-core
14:43:15 <dhellmann> so you'll be doing minimal reviews? or setting up another group to manage the branch?
14:43:41 <smcginnis> And to be clear, this is only for branches once they go to security-supported mode, so I don't expect it to decrease stable branch involvement.
14:43:51 <dhellmann> right, that was my understanding
14:43:54 <smcginnis> dhellmann: Yes, minimal reviews only.
14:44:00 <ttx> post-eol-driver-fixes/* would be a mouthful indeed
14:44:09 <smcginnis> ttx: ;)
14:44:30 <smcginnis> ttx: On the other hand, very clearly named.
14:44:31 <dhellmann> when it's all set up, it would be great to have this written up in the project team guide
14:44:32 <dhellmann> set the pattern, explain the expectations, etc.
14:44:40 <smcginnis> dhellmann: +1
14:44:48 <dhellmann> smcginnis : is that on your todo list?
14:44:53 <ttx> I guess I don't want people to think that this is the place where driver fixes go. It's the place where driver fixes go after eol, and those are untested
14:45:06 <smcginnis> Once all the puzzle pieces are in place I plan on writing up a Cinder devref and ML post explaining it.
14:45:17 <smcginnis> Hopefully we can adapt that for the project team guide.
14:45:18 <ttx> I guess that should be made clear with the branch name though
14:45:27 <dhellmann> smcginnis : ++
14:45:43 <ttx> i.e. driverfixes/liberty when stable/liberty is dead, should make it pretty clear.
14:45:54 <fungi> i got the impression it wasn't _just_ after eol
14:45:55 <smcginnis> ttx: That's my hope.
14:46:07 <fungi> but also fixes which wouldn't be approved by the stable branch maintainers
14:46:09 <smcginnis> security mode and oel
14:46:16 <ttx> fungi: unstable/liberty :)
14:46:18 <dhellmann> yeah, it's not quite eol, is it? it's when it goes into security mode, which is a bit before eol
14:46:25 <smcginnis> ttx: That was my suggestion! :)
14:46:45 <smcginnis> eol as far as the driver maintainers go. :]
14:46:53 <ttx> sandbox/liberty
14:47:03 <smcginnis> And key word in fungi's statement: fixes
14:47:10 <smcginnis> No backporting new driver features.
14:47:22 <dhellmann> right, it's limited to fixing issues in the drivers
14:47:29 <ttx> oh well, worst case scenario it's not hard to rename branches
14:47:54 <dhellmann> it's a new thing. we still have folks who don't understand what stable/ means, too.
14:47:58 <smcginnis> And if this turns into an unforeseen disaster, I'm OK saying we tried our best and call it a failure.
14:47:59 <ttx> The important part being to standardize on a common prefix
14:48:04 <smcginnis> But I really hope that doesn't happen.
14:48:12 <dhellmann> smcginnis : so a retrospective at the ptg?
14:48:15 <dhellmann> ttx: right
14:48:17 <fungi> i have suspicions this won't actually help the situation in any way, but it's worth a try and if the experiment fails it's not like you have to keep doing it
14:48:35 <smcginnis> dhellmann: Sure, that can't hurt. Could also be a good way to educate on it's use/existence.
14:48:47 <dhellmann> smcginnis : yep
14:48:50 <ttx> +2
14:48:58 <smcginnis> fungi: Package maintainers have been asking for this for a while.
14:49:08 <dhellmann> so we're all ok with the name as it is, at least for now?
14:49:14 <ttx> +2
14:49:24 <dhellmann> cool
14:49:38 <fungi> i mean, we heard similar stories about why we should keep stable branches around for longer because distros would be submitting patches there, but most of the time it's only upstream devs submitting patches so once they stop caring the distro package maintainers just do their backporting in isolation anyway
14:50:13 <fungi> this has been the schizophrenic definition of our stable branches for as long as i've been involved in openstack
14:50:24 <ttx> #agreed let's give driverfixes/* a try
14:50:34 <ttx> #topic open discussion
14:50:43 <smcginnis> fungi: True. But that's why I've wanted to make it clear this is not in any way considered "stable". :)
14:50:47 <ttx> dhellmann: maybe read the first part of the meeting and let us know what you think
14:50:49 <dhellmann> yes, I think this was a compromise between expanding stable support and forcing vendors to maintain forks, which then result in the inability to mix drivers from different providers in a deployment
14:50:56 <dims> belated +2 on driverfixes/*
14:50:59 <dhellmann> ttx, I was just going to ask if there was anything else you deferred
14:51:15 * smcginnis goes back to trying to figure layout.yaml
14:51:20 <ttx> not really but you migth want to chime in on some
14:51:39 <ttx> especially the first one
14:52:15 <dhellmann> the deliverable file changes?
14:52:20 <ttx> yes
14:52:33 <ttx> and who will be affected / we should talk to
14:52:44 <dhellmann> I like the idea of building a single yaml file with the deliverable tags to make it easier for someone to consume the results
14:53:46 <dhellmann> that would solve the navigator issue, I guess
14:53:59 <dhellmann> and I was specifically trying to find out who to talk to on the team that builds that
14:54:12 <dhellmann> is that outsourced from the foundation?
14:55:02 <ttx> dhellmann: that would be Jimmy McArthur on staff
14:55:18 <dhellmann> ok, maybe I can get his contact info from you separately then
14:55:20 <ttx> he coordinates who ends up doing it
14:55:30 <ttx> I can handle the comms there
14:55:53 <ttx> once we have a clear detailed plan and some buy-in from the TC, I can engage
14:55:57 <dhellmann> ok. my plan for now is to start by putting the data we need in the releases repo, and then stop pulling data from the governance repo at all
14:56:13 <ttx> but I don't expect there to be any problem, especially if we generate that single file
14:56:15 <dhellmann> then we can deal with publishing any extra data files for them to make their lives easier
14:56:26 <ttx> they already get data from several sources to aggregate them
14:56:27 <dhellmann> it would be 1 per series
14:56:36 <dhellmann> since the whole point is this stuff changes over time
14:57:20 <dhellmann> but I can just plan on building out the single yaml file if we expect that to be the thing they request
14:57:45 <dhellmann> time is almost up, is there anything else?
14:58:00 <fungi> and i guess we only ever publish for the current cycle, since there aren't per-cycle copies of our governance reference data
14:58:41 <dhellmann> fungi : that's a good point
14:59:21 <dhellmann> alright, I think that's it for today
14:59:30 <dhellmann> apologies again for being late, and thanks ttx for starting the meeting without me
14:59:37 <ttx> np
14:59:43 <ttx> #endmeeting