14:03:42 #startmeeting releaseteam 14:03:42 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:45 The meeting name has been set to 'releaseteam' 14:03:57 courtesy ping: ttx, dims, Jokke_, lifeless 14:03:58 o/ 14:04:01 o/ 14:04:08 o/ 14:04:11 lurking here for anything interesting 14:04:21 our agenda is in the r-20 section of the mitaka plan etherpad 14:04:24 welcome Jokke_ ! 14:04:25 #link https://etherpad.openstack.org/p/mitaka-relmgt-plan 14:04:40 #topic actions from last week 14:04:46 * dhellmann check with infra about the difficulty of moving the release repo publishing 14:05:00 * dhellmann add details about moving release publishing to the mitaka plan 14:05:02 both of those are done 14:05:18 ajaeger gave me some tips about the migration 14:05:40 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 thoughts? 14:06:23 right, no prio 14:06:34 ok, moving on 14:06:36 sounds good 14:06:55 #topic milestone tagging instructions 14:07:16 next week I'll send out the reminder for R-18, which includes the mitaka 1 tag 14:07:27 that reminder needs to include instructions for submitting the tag request 14:07:39 dhellmann: off-topic, shall I cut the stable/liberty branch for solumclient to your recent tag ? 14:07:41 we said we would also be removing the version entries from setup.cfg at the same time 14:07:51 ttx: oh, if they're ready for a stable branch, sure 14:08:08 oh, hmm, actually 14:08:21 maybe I shouldn't have created it for solum itself 14:08:30 since they asked for independent 14:08:34 damn confusing 14:08:46 dhellmann: that's going to the mailing list under [release] topic? 14:08:52 with their LP page being under the liberty series 14:08:58 I'll clarify 14:09:06 dhellmann: just making sure I have correct highlights ;) 14:09:15 Jokke_ : yes 14:09:21 gr8 14:09:27 ttx: yeah, our rule is not to make stable branches unless they have a series-based release model, right? 14:09:56 right. But info they gave us is conflicting. I'll clarify, no need to do anything in the mean time 14:10:12 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 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 dhellmann: if you do have some documentation about the process itself I can play around over the weekend 14:11:52 dhellmann: looks like they explicitly said "independent" now. So I should remove that branch 14:11:56 and align LP to match 14:12:25 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 I also tested with the last 2 steps in the other order (removing the version line, then tagging the previous commit) 14:13:14 Jokke_ : thanks 14:13:32 #action Jokke_ to verify that it is safe to tag and then remove version entry from setup.cfg 14:14:01 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 dhellmann: np ... can't hurt to double check nad it will be good learning excercise for me 14:15:05 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 I suppose aside from the patch, we want them to make sure they have all of their reno notes in place 14:15:58 should we require reno integration? 14:16:23 dhellmann: I think it would be fair assumption for all managed model projects to start with 14:16:45 I mean, should we require them to complete that work before we tag M1 14:17:03 dhellmann: how many are still missing ? 14:17:33 ttx: I haven't done that analysis, yet. I'll do that Monday 14:17:38 #link https://review.openstack.org/#/q/topic:add-reno,n,z 14:17:51 #action dhellmann determine which managed projects do not yet have reno integration completed 14:18:03 dhellmann: as far as instructions go... I don't think we'd require more. 14:18:15 ok, that's what I thought 14:18:27 #topic priority reviews 14:18:31 dhellmann: where are we standing on the "have gerrit post a comment on closed Lp bugs" ? 14:18:40 I don't see anything I would consider a priority, this week 14:18:47 might be bit short notice for hard requirement? 14:19:04 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 Jokke_ : I've been saying M1 since I started encouraging adoption. 14:19:52 oh, that was on my lap 14:19:59 dhellmann: hmm-m in that case, yes absolutely 14:20:33 this is good time for reminder ;) 14:20:46 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 ttx: so it was 14:20:53 leave* 14:20:56 right 14:21:05 how are we supposed to see which bugs to update ? 14:21:13 oh, I had the task of changing the default 14:21:27 by date range ? 14:21:31 I think we said we would do something like "git grep Closes-Bug" 14:21:42 ah. 14:21:46 for changes in the current release 14:21:57 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 dhellmann: makes sense 14:22:30 dims : now is good 14:22:38 dhellmann: I'll take that part, next week is pre-mitaka-1 sprint anyway 14:22:52 so we are supposed to work on all those bold items 14:22:57 ttx: ok, I'll work on the post-merge hook script changes in infra 14:23:25 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 and then we'll slose lose ends 14:23:35 close* 14:23:46 and loose* 14:23:59 ++ 14:24:17 #action dhellmann consolidate m1 sprint task list 14:24:38 ok, so about the juno EOL date, did we really not set that explicitly? 14:25:03 dhellmann : i scoured ML, wiki, did not see a specific date 14:25:44 It might be in the Vancouver etherpad 14:25:50 if someone has link to that still 14:25:56 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 let me scour 14:26:09 IIRC we agreed the shorter EOL there 14:26:29 https://etherpad.openstack.org/p/YVR-relmgt-stable-branch 14:26:51 yep ^ 14:26:58 "12 months" 14:27:04 until end of November, post summit 14:27:29 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 I'll propose dec 3 14:28:47 heh the "Why do we drop branches?" from 6-month ago looks a lot like the recent one 14:29:12 ttx: maybe that should go in the stable section of the project team guide? 14:29:21 dec 3 sounds good to me 14:29:36 are those dates we can predict for kilo and liberty already too? 14:29:57 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 dhellmann : +1 14:30:11 mordred: that same etherpad says 9 months for kilo 14:30:26 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 "stable community" === unicorns? :) 14:31:50 ttx: I don't remember a stable branch discussion about liberty at this summit. Did we have one? 14:31:52 dhellmann: I think we settled for 13 months since then, can't find ref 14:32:25 ok, I like standards 14:32:50 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 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 ++ 14:33:46 of course, soon this will be up to the stable team, right? 14:33:57 dhellmann: yup. I'll be more than happy to 14:34:01 dhellmann: _Not_ alone 14:34:01 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 mordred : thanks 14:34:21 dhellmann: (I could probably calculate 6-months-from-dec-3 too, yeah? 14:34:35 I think stable/kilo went relatively well compared to stable/juno back when we were in Vancouver 14:34:45 mordred: slipping the second EOL as well :P 14:34:45 mordred : probably, if that takes into account holidays and actual summit dates 14:34:54 So basically we could say that we don't extend Juno but we extend Kilo to match Juno 14:35:11 and do not reduce it as was considered 14:35:28 ttx: ++ 14:35:29 dhellmann: nod 14:35:31 yeah, I agree with that, kilo seems like it has gone much better than juno did 14:35:47 #action mordred to propose specific EOL dates for kilo and liberty 14:35:53 \o/ 14:36:12 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 where's the easiest place to find the release dates for kilo and liberty? 14:36:39 ttx: yah. also, kilo doesn't have the python2.6 depend on it like juno does 14:36:39 http://docs.openstack.org/releases/ ? 14:36:56 #agreed standardize on 13 month support window for stable branches, for now 14:37:01 ttx: nope. there are no release dates there 14:37:05 https://wiki.openstack.org/wiki/Liberty_Release_Schedule 14:37:22 ttx: I don't think there are dates on any of those pages, ironically 14:37:36 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 heh 14:37:50 https://wiki.openstack.org/wiki/Kilo_Release_Schedule 14:37:56 cool 14:38:02 yeah, liberty schedule if you don't want to read dates on tags 14:38:05 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 but we could at least add basic dat info to the series pages manually 14:38:34 does someone want to do that? 14:38:38 * dhellmann looks at mordred again 14:38:45 :) 14:39:16 heh 14:39:23 what have I gotten myself in to 14:39:34 mordred : welcome to the release team! 14:39:38 yay! 14:39:44 now I can really retire on an island 14:40:05 let's move on, one more topic on the agenda 14:40:10 #topic release models for neutron stadium projects following after the main release cycle 14:40:15 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079773.html 14:40:28 * ttx cries 14:40:51 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 So it's not just neutron stadium things (for which you could argue that they should try to release in sync) 14:41:10 yeah, I expect we already (or will) have others 14:41:15 Fuel is another one for which releasing is defered 14:41:50 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 Freezer is currently working their way to get to sync 14:42:04 if we start making "liberty" mean different dates to different people, we lose that 14:42:11 and that would make me a very sad panda 14:42:38 I'm worried about the message it sends for some projects to be doing active development on a stable branch, too 14:42:41 ttx : am pushing fuel to do the right thing for Mitaka 14:43:03 so I'd like to veto the "cycle-with-intermediary's liberty may end three months into mitaka" option 14:43:06 dhellmann: that we just should not allow 14:43:48 now we may want to explicitly designate laggards 14:44:00 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 some "will-track-releases" model 14:44:19 might also be an option 14:44:31 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 dhellmann: that might be bit problematic message as well 14:45:31 Jokke_ : yes 14:45:58 Projects under a "will-track-releases" model could use some "for/liberty" branches that would not technically be "liberty" releases 14:46:10 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 as long as it's clear it's downstream I think I can live with it 14:46:39 ttx: so add a new branch prefix for this purpose, to differentiate between it and stable? 14:47:17 the trick is last time I proposed something like that (with backport/liberty) infra told me that was hell 14:47:18 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 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 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 dhellmann: ++ 14:48:33 i don't think having plenty of projects compatible with various stages of development is such a great experience for users 14:48:54 like if Freezer can only work with kilo 14:49:14 "I deploy liberty and I can't run freezer" 14:49:17 ttx: not only work with kilo, they wanted to ensure that it works with kilo 14:49:30 Jokke_ : hypothetical example 14:49:38 yeah ^ 14:49:52 but yes I do agree that it's not great user/deployer experience 14:50:04 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 shouldn't have the case that you deploy from master and you don't have working series even in theory 14:50:36 not even starting to talk about testing 14:50:55 yeah, that's a good summary of the problem 14:51:06 let's rewind a bit 14:51:09 so how do we clarify the message? 14:51:14 which cases do we have ? 14:51:27 there is the neutron stadium drivers that lag behind the neutron release 14:51:32 we have new projects like networking-bgpvpn, right 14:51:41 that, I think, is an accident 14:51:50 neutron freezes very early 14:52:02 they should be able to finalize their compatibility work in that time 14:52:09 should Neutron have earlier freeze to facilitate the stadium drivers to be in sync for the release? 14:52:11 ttx: we're almost at M1 though, and bgpvpn doesn't have a liberty release 14:52:16 it's added value for them to be available at the same time 14:52:40 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 hmm, they might mind that :-) 14:53:39 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 and telling them that they need to have it cut by M-1 might give really broken stable/liberty 14:53:50 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 dhellmann: that's the fallback if we hold that line yes 14:54:35 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 Then there is the fuel case. They do independent with version numbers and a dictionary saying "6.0 is for liberty" 14:54:50 I don't mind them doing that until they can converge 14:54:56 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 ttx sounds good 14:55:17 ttx: yeah, independent seems right for fuel 14:55:29 ttx: but maintaining that would need some branch they can store that state 14:55:35 basically we are saying the "liberty" label is for everyone that can release at around the same time 14:55:52 all the others have to use a mapping 14:56:07 where does fuel do that now, in their documentation? 14:56:09 I still feel it's better than diluting what "liberty" means 14:56:10 so can they have stable/6 and document that it's for liberty? 14:56:23 Jokke_: sure 14:56:31 dhellmann: I think so 14:56:32 we have the highlights field in the releases repo, so they could include a note there, too 14:56:44 ttx: ok that would make perfectly sense for me at least 14:57:06 The difference being "6.0 is liberty" vs. "6.0 is for liberty" 14:57:36 yeah 14:57:45 so then I have next question about that 14:57:46 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 ok, I'm comfortable with this, based on the "the name is for projects releasing during the cycle" rule 14:58:26 but we totally need to allow stable/6.0 (we already do but we have unclear messaging around it) 14:58:26 ttx: yeah, I think that's what they'll probably end up doing 14:58:33 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 dhellmann: I feel like it's better than saying "mitaka-1 is for liberty" 14:58:59 ttx: yeah, that would be very confusing 14:59:17 Jokke_ : which project? 14:59:23 freezer 14:59:42 Jokke_ : we should probably rename the kilo branch, yes 15:00:07 so first stable/ for them will be stable/mitaka 15:00:07 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 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 ++ 15:00:46 we'd basically consider making them release:independent if they can't follow the cycle-with-* model 15:00:51 it all makes sense 15:01:12 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 ++ dhellmann 15:01:16 and we're out of time 15:01:25 oh, thanks Jokke_ 15:01:26 moving back to our burrow 15:01:41 this was good round, thanks all 15:01:41 yeah, let's move to #openstack-release 15:01:47 thanks, everyone 15:01:49 #endmeeting