14:03:42 <dhellmann> #startmeeting releaseteam
14:03:42 <openstack> Meeting started Fri Nov 20 14:03:42 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:45 <openstack> The meeting name has been set to 'releaseteam'
14:03:57 <dhellmann> courtesy ping: ttx, dims, Jokke_, lifeless
14:03:58 <ttx> o/
14:04:01 <Jokke_> o/
14:04:08 <dims> o/
14:04:11 <Jokke_> lurking here for anything interesting
14:04:21 <dhellmann> our agenda is in the r-20 section of the mitaka plan etherpad
14:04:24 <dims> welcome Jokke_ !
14:04:25 <dhellmann> #link https://etherpad.openstack.org/p/mitaka-relmgt-plan
14:04:40 <dhellmann> #topic actions from last week
14:04:46 <dhellmann> * dhellmann check with infra about the difficulty of moving the release repo publishing
14:05:00 <dhellmann> * dhellmann add details about moving release publishing to the mitaka plan
14:05:02 <dhellmann> both of those are done
14:05:18 <dhellmann> ajaeger gave me some tips about the migration
14:05:40 <dhellmann> I think we have some more important things to do for now, so I wasn't going to make that an especially high priority until later in the cycle
14:05:42 <dhellmann> thoughts?
14:06:23 <ttx> right, no prio
14:06:34 <dhellmann> ok, moving on
14:06:36 <dims> sounds good
14:06:55 <dhellmann> #topic milestone tagging instructions
14:07:16 <dhellmann> next week I'll send out the reminder for R-18, which includes the mitaka 1 tag
14:07:27 <dhellmann> that reminder needs to include instructions for submitting the tag request
14:07:39 <ttx> dhellmann: off-topic, shall I cut the stable/liberty branch for solumclient to your recent tag ?
14:07:41 <dhellmann> we said we would also be removing the version entries from setup.cfg at the same time
14:07:51 <dhellmann> ttx: oh, if they're ready for a stable branch, sure
14:08:08 <ttx> oh, hmm, actually
14:08:21 <ttx> maybe I shouldn't have created it for solum itself
14:08:30 <ttx> since they asked for independent
14:08:34 <ttx> damn confusing
14:08:46 <Jokke_> dhellmann: that's going to the mailing list under [release] topic?
14:08:52 <ttx> with their LP page being under the liberty series
14:08:58 <ttx> I'll clarify
14:09:06 <Jokke_> dhellmann: just making sure I have correct highlights ;)
14:09:15 <dhellmann> Jokke_ : yes
14:09:21 <Jokke_> gr8
14:09:27 <dhellmann> ttx: yeah, our rule is not to make stable branches unless they have a series-based release model, right?
14:09:56 <ttx> right. But info they gave us is conflicting. I'll clarify, no need to do anything in the mean time
14:10:12 <dhellmann> I think I've worked out that it's safe to land the version number change and then tag a previous commit, but I'd like some independent verification of that. does someone have time to run that experiement?
14:10:50 <dhellmann> I want to make sure we don't end up with version numbers decreasing on master, or with master blocked when the version number is removed if we haven't tagged yet
14:11:34 <Jokke_> dhellmann: if you do have some documentation about the process itself I can play around over the weekend
14:11:52 <ttx> dhellmann: looks like they explicitly said "independent" now. So I should remove that branch
14:11:56 <ttx> and align LP to match
14:12:25 <dhellmann> I tested by creating a scratch repo, committing something and tagging it, then committing 2 more changes, tagging the last, then removing version from setup.cfg and trying to commit something else and build a package from the results (pbr throws an error if the version instructions conflict)
14:12:55 <dhellmann> I also tested with the last 2 steps in the other order (removing the version line, then tagging the previous commit)
14:13:14 <dhellmann> Jokke_ : thanks
14:13:32 <dhellmann> #action Jokke_ to verify that it is safe to tag and then remove version entry from setup.cfg
14:14:01 <dhellmann> ttx: do we have anything else special we need to include in the instructions, other than to submit the patch to the releases repo?
14:14:10 <Jokke_> dhellmann: np ... can't hurt to double check nad it will be good learning excercise for me
14:15:05 <dhellmann> we need to update the release script to skip all of the launchpad work it does now so we can use it for milestones, too. probably by making a new script and changing release_from_yaml.py to call that instead of release_postversion.sh
14:15:44 <dhellmann> I suppose aside from the patch, we want them to make sure they have all of their reno notes in place
14:15:58 <dhellmann> should we require reno integration?
14:16:23 <Jokke_> dhellmann: I think it would be fair assumption for all managed model projects to start with
14:16:45 <dhellmann> I mean, should we require them to complete that work before we tag M1
14:17:03 <ttx> dhellmann: how many are still missing ?
14:17:33 <dhellmann> ttx: I haven't done that analysis, yet. I'll do that Monday
14:17:38 <dhellmann> #link https://review.openstack.org/#/q/topic:add-reno,n,z
14:17:51 <dhellmann> #action dhellmann determine which managed projects do not yet have reno integration completed
14:18:03 <ttx> dhellmann: as far as instructions go... I don't think we'd require more.
14:18:15 <dhellmann> ok, that's what I thought
14:18:27 <dhellmann> #topic priority reviews
14:18:31 <ttx> dhellmann: where are we standing on the "have gerrit post a comment on closed Lp bugs" ?
14:18:40 <dhellmann> I don't see anything I would consider a priority, this week
14:18:47 <Jokke_> might be bit short notice for hard requirement?
14:19:04 <dhellmann> ttx: I haven't started that work. I was going to try to get to it this week, but didn't, so I'm hoping next week unless someone else wants to pick it up.
14:19:26 <dhellmann> Jokke_ : I've been saying M1 since I started encouraging adoption.
14:19:52 <ttx> oh, that was on my lap
14:19:59 <Jokke_> dhellmann: hmm-m in that case, yes absolutely
14:20:33 <Jokke_> this is good time for reminder ;)
14:20:46 <ttx> dhellmann: on that front... we were saying that we would "eave comments on bugs about the release with the fix instead of changing the status"
14:20:47 <dhellmann> ttx: so it was
14:20:53 <ttx> leave*
14:20:56 <dhellmann> right
14:21:05 <ttx> how are we supposed to see which bugs to update ?
14:21:13 <dhellmann> oh, I had the task of changing the default
14:21:27 <ttx> by date range ?
14:21:31 <dhellmann> I think we said we would do something like "git grep Closes-Bug"
14:21:42 <ttx> ah.
14:21:46 <dhellmann> for changes in the current release
14:21:57 <dims> dhellmann : mordred was asking about Juno EOL date in https://review.openstack.org/#/c/247677/ do we talk about it in this topic or in open discussion?
14:22:06 <ttx> dhellmann: makes sense
14:22:30 <dhellmann> dims : now is good
14:22:38 <ttx> dhellmann: I'll take that part, next week is pre-mitaka-1 sprint anyway
14:22:52 <ttx> so we are supposed to work on all those bold items
14:22:57 <dhellmann> ttx: ok, I'll work on the post-merge hook script changes in infra
14:23:25 <dhellmann> yeah, it would be good to get that list all in one place, maybe under the calendar, so it's easier to see what we need to do next week
14:23:32 <ttx> and then we'll slose lose ends
14:23:35 <ttx> close*
14:23:46 <ttx> and loose*
14:23:59 <dhellmann> ++
14:24:17 <dhellmann> #action dhellmann consolidate m1 sprint task list
14:24:38 <dhellmann> ok, so about the juno EOL date, did we really not set that explicitly?
14:25:03 <dims> dhellmann : i scoured ML, wiki, did not see a specific date
14:25:44 <Jokke_> It might be in the Vancouver etherpad
14:25:50 <Jokke_> if someone has link to that still
14:25:56 <dhellmann> I'm inclined to wait for fungi to return next week to get his thoughts on apevec's comment on that review
14:25:58 <ttx> let me scour
14:26:09 <Jokke_> IIRC we agreed the shorter EOL there
14:26:29 <dims> https://etherpad.openstack.org/p/YVR-relmgt-stable-branch
14:26:51 <ttx> yep ^
14:26:58 <dhellmann> "12 months"
14:27:04 <ttx> until end of November, post summit
14:27:29 <dhellmann> so it sounds like alan's comment of nov 26 is probably right, though since that's thanksgiving it may be until the following week
14:28:02 <dhellmann> I'll propose dec 3
14:28:47 <ttx> heh the "Why do we drop branches?" from 6-month ago looks a lot like the recent one
14:29:12 <dhellmann> ttx: maybe that should go in the stable section of the project team guide?
14:29:21 <mordred> dec 3 sounds good to me
14:29:36 <mordred> are those dates we can predict for kilo and liberty already too?
14:29:57 <Jokke_> ttx: indeed ... only difference is that this time there is at least promises to something around resourcing ... maybe by Unicorn we actually have that stable community to have all this happening :D
14:30:10 <dims> dhellmann : +1
14:30:11 <dhellmann> mordred: that same etherpad says 9 months for kilo
14:30:26 <ttx> well yes, At this stage we said 13 months support (i.e. one month after release to leave time after summit to do it
14:30:55 <dims> "stable community" === unicorns? :)
14:31:50 <dhellmann> ttx: I don't remember a stable branch discussion about liberty at this summit. Did we have one?
14:31:52 <ttx> dhellmann: I think we settled for 13 months since then, can't find ref
14:32:25 <dhellmann> ok, I like standards
14:32:50 <dhellmann> mordred : do you want to do the 13 month calculations for kilo and liberty and propose separate patches for those, too with "estimated EOL dates"?
14:33:20 <ttx> I think it's doable to do 13 months for kilo if we don't do more than 13 months for juno. The idea being you only support 3 branches for one month, time to EOL the last one
14:33:36 <dhellmann> ++
14:33:46 <dhellmann> of course, soon this will be up to the stable team, right?
14:33:57 <mordred> dhellmann: yup. I'll be more than happy to
14:34:01 <Jokke_> dhellmann: _Not_ alone
14:34:01 <ttx> 9 months was an aggressive suggestion based on a lot of unknowns with the constraints being put in place and how fast we'd want to move to the new shiny
14:34:02 <dhellmann> mordred : thanks
14:34:21 <mordred> dhellmann: (I could probably calculate 6-months-from-dec-3 too, yeah?
14:34:35 <ttx> I think stable/kilo went relatively well compared to stable/juno back when we were in Vancouver
14:34:45 <Jokke_> mordred: slipping the second EOL as well :P
14:34:45 <dhellmann> mordred : probably, if that takes into account holidays and actual summit dates
14:34:54 <ttx> So basically we could say that we don't extend Juno but we extend Kilo to match Juno
14:35:11 <ttx> and do not reduce it as was considered
14:35:28 <Jokke_> ttx: ++
14:35:29 <mordred> dhellmann: nod
14:35:31 <dhellmann> yeah, I agree with that, kilo seems like it has gone much better than juno did
14:35:47 <dhellmann> #action mordred to propose specific EOL dates for kilo and liberty
14:35:53 <mordred> \o/
14:36:12 <ttx> I don't think we could justify in the current situation to not only drop Juno now but also drop Kilo in 2 months
14:36:14 <mordred> where's the easiest place to find the release dates for kilo and liberty?
14:36:39 <mordred> ttx: yah. also, kilo doesn't have the python2.6 depend on it like juno does
14:36:39 <ttx> http://docs.openstack.org/releases/ ?
14:36:56 <dhellmann> #agreed standardize on 13 month support window for stable branches, for now
14:37:01 <mordred> ttx: nope. there are no release dates there
14:37:05 <dims> https://wiki.openstack.org/wiki/Liberty_Release_Schedule
14:37:22 <dhellmann> ttx: I don't think there are dates on any of those pages, ironically
14:37:36 <mordred> ttx: (this sort of got me in to a "the releases repo is awesome, but lacks any date information for anything" kick)
14:37:46 <ttx> heh
14:37:50 <dims> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
14:37:56 <mordred> cool
14:38:02 <ttx> yeah, liberty schedule if you don't want to read dates on tags
14:38:05 <dhellmann> yeah, the dates for those tags are in *other* repos, so we'd have to clone all of openstack to build it automatically. Which we can do, but I haven't yet.
14:38:25 <dhellmann> but we could at least add basic dat info to the series pages manually
14:38:34 <dhellmann> does someone want to do that?
14:38:38 * dhellmann looks at mordred again
14:38:45 <dims> :)
14:39:16 <mordred> heh
14:39:23 <mordred> what have I gotten myself in to
14:39:34 <dhellmann> mordred : welcome to the release team!
14:39:38 <dims> yay!
14:39:44 <ttx> now I can really retire on an island
14:40:05 <dhellmann> let's move on, one more topic on the agenda
14:40:10 <dhellmann> #topic release models for neutron stadium projects following after the main release cycle
14:40:15 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079773.html
14:40:28 * ttx cries
14:40:51 <dhellmann> this thread was about how to handle projects that want to release liberty-compatible deliverables after liberty is "done" for most of the other projects
14:40:56 <ttx> So it's not just neutron stadium things (for which you could argue that they should try to release in sync)
14:41:10 <dhellmann> yeah, I expect we already (or will) have others
14:41:15 <ttx> Fuel is another one for which releasing is defered
14:41:50 <ttx> My take on it is that development cycles are one of the very few things we have in common as a reference point for this community
14:41:51 <Jokke_> Freezer is currently working their way to get to sync
14:42:04 <ttx> if we start making "liberty" mean different dates to different people, we lose that
14:42:11 <ttx> and that would make me a very sad panda
14:42:38 <dhellmann> I'm worried about the message it sends for some projects to be doing active development on a stable branch, too
14:42:41 <dims> ttx : am pushing fuel to do the right thing for Mitaka
14:43:03 <ttx> so I'd like to veto the "cycle-with-intermediary's liberty may end three months into mitaka" option
14:43:06 <Jokke_> dhellmann: that we just should not allow
14:43:48 <ttx> now we may want to explicitly designate laggards
14:44:00 <dhellmann> so does that leave us with telling projects to use the independent release model until they can work in sync, and that they cannot have stable branches under that model, so they have to do this work on master?
14:44:09 <ttx> some "will-track-releases" model
14:44:19 <ttx> might also be an option
14:44:31 <persia> There are a number of organisations with commercial practices that involve postponing *starting* work on something until the "release date", after which they conform their new features to that stable base.  As more of those are proposed to big tent, this problem may grow.  Education about collaborating against active development targets is probably the best defense against loss of coherence.
14:44:57 <Jokke_> dhellmann: that might be bit problematic message as well
14:45:31 <dhellmann> Jokke_ : yes
14:45:58 <ttx> Projects under a "will-track-releases" model could use some "for/liberty" branches that would not technically be "liberty" releases
14:46:10 <dhellmann> persia : if they do the work during SERIES but it's only compatible with SERIES-1 I'm not sure we shouldn't call that the SERIES release for that project
14:46:15 <ttx> as long as it's clear it's downstream I think I can live with it
14:46:39 <dhellmann> ttx: so add a new branch prefix for this purpose, to differentiate between it and stable?
14:47:17 <ttx> the trick is last time I proposed something like that (with backport/liberty) infra told me that was hell
14:47:18 <persia> dhellmann: With an explicit note that that project is out-of-sync and potentially incompatible with the rest of SERIES?  I like "will-track" better, for all that I don't like any of it.
14:47:18 <Jokke_> what I do know about Freezer is that they want to be in sync ... their development was just basically against Kilo, now they are working last bits they want to have tagged as "working with OpenStack Liberty release and we want to maintain that" and we try really hard to push to do actual mitaka since M-1
14:48:14 <dhellmann> ttx: what if we stop using the name stable, and had everyone create a series/foo branch, then use the tag to indicate whether it's stable or not?
14:48:29 <Jokke_> dhellmann: ++
14:48:33 <ttx> i don't think having plenty of projects compatible with various stages of development is such a great experience for users
14:48:54 <ttx> like if Freezer can only work with kilo
14:49:14 <ttx> "I deploy liberty and I can't run freezer"
14:49:17 <Jokke_> ttx: not only work with kilo, they wanted to ensure that it works with kilo
14:49:30 <dhellmann> Jokke_ : hypothetical example
14:49:38 <ttx> yeah ^
14:49:52 <Jokke_> but yes I do agree that it's not great user/deployer experience
14:50:04 <ttx> my point is, we propose a set of interoperable projects, if we inject a dimension of version compatibility on top, that becomes a mess
14:50:16 <Jokke_> shouldn't have the case that you deploy from master and you don't have working series even in theory
14:50:36 <ttx> not even starting to talk about testing
14:50:55 <dhellmann> yeah, that's a good summary of the problem
14:51:06 <ttx> let's rewind a bit
14:51:09 <dhellmann> so how do we clarify the message?
14:51:14 <ttx> which cases do we have ?
14:51:27 <ttx> there is the neutron stadium drivers that lag behind the neutron release
14:51:32 <dhellmann> we have new projects like networking-bgpvpn, right
14:51:41 <ttx> that, I think, is an accident
14:51:50 <ttx> neutron freezes very early
14:52:02 <ttx> they should be able to finalize their compatibility work in that time
14:52:09 <Jokke_> should Neutron have earlier freeze to facilitate the stadium drivers to be in sync for the release?
14:52:11 <dhellmann> ttx: we're almost at M1 though, and bgpvpn doesn't have a liberty release
14:52:16 <ttx> it's added value for them to be available at the same time
14:52:40 <ttx> and I think that's because they were not operational and mature enough. I wouldn't mind them not doing a liberty release at all.
14:52:54 <dhellmann> hmm, they might mind that :-)
14:53:39 <ttx> well, maybe they should have thought about that before starting the stadium. Will the spin-out things be able to release ? Sounds like a pretty important factor
14:53:45 <Jokke_> and telling them that they need to have it cut by M-1 might give really broken stable/liberty
14:53:50 <dhellmann> do we tell them they can release, but it's going to be a mitaka release even if it's only compatible with liberty?
14:54:04 <ttx> dhellmann: that's the fallback if we hold that line yes
14:54:35 <dhellmann> ok. I think I'm comfortable with that, but it does bring up the issue that their mitaka release may not be compatible with mitaka neutron.
14:54:36 <ttx> Then there is the fuel case. They do independent with version numbers and a dictionary saying "6.0 is for liberty"
14:54:50 <ttx> I don't mind them doing that until they can converge
14:54:56 <dhellmann> the other networking project did say they're supporting kilo, liberty, and mitaka all from their master branch, so it's possible
14:55:13 <dims> ttx sounds good
14:55:17 <dhellmann> ttx: yeah, independent seems right for fuel
14:55:29 <Jokke_> ttx: but maintaining that would need some branch they can store that state
14:55:35 <ttx> basically we are saying the "liberty" label is for everyone that can release at around the same time
14:55:52 <ttx> all the others have to use a mapping
14:56:07 <dhellmann> where does fuel do that now, in their documentation?
14:56:09 <ttx> I still feel it's better than diluting what "liberty" means
14:56:10 <Jokke_> so can they have stable/6 and document that it's for liberty?
14:56:23 <ttx> Jokke_: sure
14:56:31 <ttx> dhellmann: I think so
14:56:32 <dhellmann> we have the highlights field in the releases repo, so they could include a note there, too
14:56:44 <Jokke_> ttx: ok that would make perfectly sense for me at least
14:57:06 <ttx> The difference being "6.0 is liberty" vs. "6.0 is for liberty"
14:57:36 <Jokke_> yeah
14:57:45 <Jokke_> so then I have next question about that
14:57:46 <ttx> dhellmann: one could argue that the fuel model (independent with manual series mapping) is also a solution for the neutron stadium islands
14:57:55 <dhellmann> ok, I'm comfortable with this, based on the "the name is for projects releasing during the cycle" rule
14:58:26 <ttx> but we totally need to allow stable/6.0 (we already do but we have unclear messaging around it)
14:58:26 <dhellmann> ttx: yeah, I think that's what they'll probably end up doing
14:58:33 <Jokke_> should we branch out stable/1.1 from freezer stable/kilo, remove the stable/kilo that was created and document that mapping
14:58:45 <ttx> dhellmann: I feel like it's better than saying "mitaka-1 is for liberty"
14:58:59 <dhellmann> ttx: yeah, that would be very confusing
14:59:17 <dhellmann> Jokke_ : which project?
14:59:23 <Jokke_> freezer
14:59:42 <dhellmann> Jokke_ : we should probably rename the kilo branch, yes
15:00:07 <Jokke_> so first stable/<name> for them will be stable/mitaka
15:00:07 <ttx> dhellmann: so we tolerated late releases for liberty because we were still figuring out things, but unlikely that we would extend the window for mitaka
15:00:24 <dhellmann> before we do anything, though, let's summarize this discussion on a mailing list thread and get the rules written down somewhere in a git repo
15:00:33 <Jokke_> ++
15:00:46 <ttx> we'd basically consider making them release:independent if they can't follow the cycle-with-* model
15:00:51 <ttx> it all makes sense
15:01:12 <dhellmann> ttx: yeah, I think that's reasonable, and we've gone long enough into mitaka that I'm ok not making any more liberty branches for any projects
15:01:14 <dims> ++ dhellmann
15:01:16 <Jokke_> and we're out of time
15:01:25 <dhellmann> oh, thanks Jokke_
15:01:26 <ttx> moving back to our burrow
15:01:41 <Jokke_> this was good round, thanks all
15:01:41 <dhellmann> yeah, let's move to #openstack-release
15:01:47 <dhellmann> thanks, everyone
15:01:49 <dhellmann> #endmeeting