Thursday, 2020-06-11

*** hongbin has quit IRC00:16
*** hongbin has joined #openstack-release00:34
*** hongbin has quit IRC01:42
*** ricolin has joined #openstack-release02:39
*** hongbin has joined #openstack-release02:43
*** tetsuro has quit IRC03:16
*** tetsuro has joined #openstack-release03:54
*** evrardjp has quit IRC04:33
*** hongbin has quit IRC04:33
*** evrardjp has joined #openstack-release04:33
*** ykarel|away is now known as ykarel04:37
*** vishalmanchanda has joined #openstack-release05:35
*** tetsuro_ has joined #openstack-release05:45
*** tetsuro__ has joined #openstack-release05:47
*** tetsuro has quit IRC05:47
*** tetsuro_ has quit IRC05:50
*** udesale has joined #openstack-release06:02
*** udesale has quit IRC06:17
*** udesale has joined #openstack-release06:18
*** jbadiapa has quit IRC06:23
*** jbadiapa has joined #openstack-release06:30
*** dustinc has quit IRC06:35
*** rpittau|afk is now known as rpittau07:18
*** amoralej|off is now known as amoralej07:25
*** tetsuro__ has quit IRC07:37
*** tosky has joined #openstack-release07:38
*** tetsuro has joined #openstack-release07:40
*** ykarel is now known as ykarel|lunch07:53
*** slaweq has quit IRC08:15
*** slaweq has joined #openstack-release08:20
*** e0ne has joined #openstack-release08:20
*** ykarel|lunch is now known as ykarel08:56
*** tetsuro has quit IRC08:57
*** tetsuro has joined #openstack-release09:00
*** rpittau is now known as rpittau|bbl09:15
*** slaweq has quit IRC09:19
*** e0ne_ has joined #openstack-release09:20
*** e0ne has quit IRC09:20
*** e0ne has joined #openstack-release09:28
*** tetsuro has quit IRC09:28
*** e0ne_ has quit IRC09:28
*** slaweq has joined #openstack-release09:57
openstackgerritMerged openstack/releases master: release oslo.utils 4.2.1
openstackgerritMerged openstack/releases master: Release horizon 16.2.0 (train)
*** slaweq has quit IRC10:20
*** slaweq has joined #openstack-release10:26
*** slaweq has quit IRC10:30
*** ricolin has quit IRC10:47
*** slaweq has joined #openstack-release11:24
*** rpittau|bbl is now known as rpittau11:54
*** amoralej is now known as amoralej|off12:08
*** amoralej|off is now known as amoralej|lunch12:08
*** slaweq has quit IRC12:13
*** slaweq has joined #openstack-release12:13
*** slaweq has quit IRC12:18
*** tkajinam has quit IRC12:25
*** mnaser has quit IRC12:32
*** gmann has quit IRC12:33
*** nicolasbock has quit IRC12:33
*** nicolasbock has joined #openstack-release12:33
*** gmann has joined #openstack-release12:33
*** mnaser has joined #openstack-release12:33
*** slaweq has joined #openstack-release12:43
*** slaweq has quit IRC12:47
*** ykarel is now known as ykarel|afk13:00
*** amoralej|lunch is now known as amoralej13:13
*** ricolin has joined #openstack-release13:51
*** ykarel|afk is now known as ykarel13:57
*** udesale_ has joined #openstack-release14:19
*** udesale has quit IRC14:22
*** slaweq has joined #openstack-release14:52
*** slaweq has quit IRC15:20
*** slaweq has joined #openstack-release15:25
*** ykarel is now known as ykarel|away15:27
*** slaweq has quit IRC15:30
ttxsmcginnis: propose we start the release meeting once the board meeting ends, which might be a few minutes late15:39
smcginnisttx: I was thinking the same thing.15:43
*** e0ne has quit IRC15:48
*** e0ne has joined #openstack-release15:49
*** rpittau is now known as rpittau|afk15:58
*** vishalmanchanda has quit IRC16:00
smcginnisttx: I had dropped earlier. Is the board meeting still going on?16:03
fungiit went into executive session16:06
fungii don't know if there was going to be another open session thereafter, but seemed like not16:06
*** dhellmann_ has joined #openstack-release16:10
*** dhellmann has quit IRC16:11
*** dhellmann_ is now known as dhellmann16:11
smcginnis#startmeeting releaseteam16:18
openstackMeeting started Thu Jun 11 16:18:36 2020 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:18
*** openstack changes topic to " (Meeting topic: releaseteam)"16:18
openstackThe meeting name has been set to 'releaseteam'16:18
smcginnisReminder to folks to add you nicks to the ping list in the new etherpad if you want that.16:19
smcginnis#link Agenda16:19
smcginnisWell, I guess it's just us today. Probably not surprising since we haven't had meetings for a few weeks.16:21
smcginnis#topic Review task completion16:21
*** openstack changes topic to "Review task completion (Meeting topic: releaseteam)"16:21
smcginnisTaks for this week was to get the list of cycle-trailing deliverables for ussuri.16:21
smcginnisThat probably needs to be updated in our process doc. I think it was this week before we pushed out the deadline for trailing projects.16:21
smcginnisBut I did run that and sent a post to the ML reminding those teams that it will need to be done.16:22
ttxI think a reminder is always good16:22
ttxwell ahead of the deadline16:22
smcginnisDoesn't hurt. I think it did trigger at least one team to do a release.16:22
ttxI was wondering about all those stable/train autoreleases -- why did we do them? is that something we should make part of the process?16:23
smcginnisI was planning on bringing that up.16:23
smcginnisI did that partly with my stable hat on.16:23
smcginnisPartly as a way to test out some automation I was working on.16:23
ttx(personally I think it's a slippery slope to start doing stable autoreleases... will add a lot of work for us?)16:23
smcginnisI do think if the automation does help (it's pretty close) then we probably should add that to our process to do those at at least a couple times during the cycle.16:24
smcginnisWhen we get around to the EM transition date, it's always this mad rush by some teams to quick get things backported while they can.16:24
ttxok, if we can get the cost near zero16:24
smcginnisRather than doing that regularly over the course of the stable branch lifecycle.16:24
ttxWhat's costly generally is to handle the ones who do not get +116:24
smcginnisAnd there are a few teams that are pretty good about backporting bugfixes, but no so good about remembering to actually release those fixes.16:24
fungireleased stable branches aren't really cycle-oriented, though i guess the choice to tie timing of autoreleases to the cycle would be because the release team's activity schedule *is* cycle-oriented?16:25
ttxso maybe we should decide what to do with those ahead of time16:25
smcginnisttx: Yeah. Since this isn't an official thing, I was thinking we could jsut abandon those unacknowledged ones if we don't get a response.16:25
ttxfungi: it would not be on the release schedule, just in the team process timeline16:25
fungiright, i figured16:25
smcginnisI'm not going to go too far out of my way to help these teams that aren't paing any attention to stable maintenance.16:25
smcginnisfungi: Yep.16:26
fungibut since the team's timeline is arranged around the cycle, that's why you'd do stable autoreleases "a couple times a cycle"16:26
ttxok, as long as there is no chasing or endless meeting discussions to discuss what to do with the -1s or leftovers, I'm good :)16:26
smcginnisI thought it would be a good quieter week to get something like that out.16:26
smcginnisI'll go through and abandon any that get no response next week.16:26
ttxI just don;t want to get the impression that they need to wait for us to propose it to get a stable release out16:26
ttxbut I guess that can be worded in the commit message16:27
smcginnisMaybe next time I should add more clarification to the commit message.16:27
smcginnisAnyway, based on the responses so far, I think it was a good reminder for some teams.16:27
fungi"since the team hasn't proposed a stable release in $x days and there are $y changes merged since then, the release team is proposing this point release on your behalf..."16:27
fungisomething which reminds them they really should have been proposing releases sooner on their own16:28
smcginnisProbably even more clear that it's not something that's part of the release process, just something we're doing (or even just I'm doing) to help make sure our stable branches are in good shape and ready to be retired when the time comes.16:28
ttxyeah, maybe not say "release team"16:29
smcginnisPart of this is that when we've done the last couple of EM transitions, there were a few deliverables that had a TON of merged commits that never were released. Going back 1+ years.16:29
ttxok next16:29
smcginnisI'll try to be more clear next time.16:29
smcginnistopic Review next week's tasks16:29
smcginnisWe have the c-w-i lib releases.16:30
smcginnisThat ties in well to testing out this scripting I've been doing, so I'd like to take that one.16:30
ttxpermission granted16:30
smcginnisNext, ACL issues.16:30
ttxI can take the acl unless someone wants it16:30
hberaudnot sure what's behind16:31
smcginnisttx: I think you've become the de facto ACL man. :)16:31
smcginnisMaybe a chance to walk through it with hberaud?16:31
ttxI have a few other consistency work I've been pushing16:31
smcginnisAnd I'll send the countdown email.16:32
smcginnis#topic One release model to bind them all - open questions16:32
*** openstack changes topic to "One release model to bind them all - open questions (Meeting topic: releaseteam)"16:32
ttxright, so the discussion opened a couple of questions16:32
ttxfirst one is...16:32
ttxCan we support stable branches from arbitrary SHAs (to support the Kolla use case, but generally do give more flexibility as to when the stabilization work starts)16:32
ttxCurrently we enforce that the branch point is at a tag, for most deliverables16:33
ttxI'm.. not sure where that came from16:33
smcginnisOur validation prevents that right now, but we can change it. We do that for non-cycle based things.16:33
ttxhistorically we did manually create branches from arbitrary commits, on demand16:33
smcginnisWe allow it for things like feature branches, but enforce that tagging with stable branches.16:33
ttxthat allowed stable work to start before the RC release itself16:33
smcginnisNot really sure the background on that either.16:34
ttxwell feature branches should obviously not require to start from a tag16:34
smcginnisWe could certainly change that to create an RC branch if we want to have the stability work separated from mainline work as we lead up to final releases.16:34
funginot having a tag there does make it harder for downstream consumers to try out the candidate though16:34
ttxOK, if that does not ring a bell, I'll try to find where that requirement came from16:34
ttxit might just be taht it started that way and was cargoculted16:35
smcginnisPretty sure it was from before my time, so that may take some digging.16:35
smcginnisCould be.16:35
ttxAt first glance i can;t see why that would be necessary16:35
smcginnisRelease note generation?16:36
fungifor testing purposes, it may still be that you'd want to encourage most projects to branch from an initial tag anyway16:36
ttxI'll ask dhellmann if that rings a bell for him16:36
fungiand branching from an arbitrary commit in master would be an exception rather than commonplace16:37
ttxanyway, allowing it now would give a bit more flexibility16:37
ttxso you can start the stabilization work slightly ahead of when you think you have a great release candidate16:38
ttxMost of the reaction on that thread seems to be around confusing marketing release numbers and semver numbers16:39
ttxLike a release should be x.0.0!16:39
smcginnisIt may be reno. Thinking about that, the common tag between the two branches would be a point before the last cycle branched, so release notes may include duplicate changes in both N and N-1 notes.16:39
ttxI'd say that finally letting go of marketing numbers is a good thing16:40
ttxespecially since half the openstack world has already moved on16:40
ttxok, second question...16:41
smcginnisI'm a little concerned about the corner case I pointed out earlier today. Occasionally breaking changes have been merged between RCs.16:41
smcginnisAnd two major version bumps within a short timeframe could be a little confusing.16:41
ttxoh you mean respecting semver in prereleases16:41
ttxrelease number inflation around pre-releases16:42
ttxIt's another case of conflating marketing and semver numbers16:42
smcginnisThat's just semver.16:42
smcginnisNo marketing involved.16:42
fungithe horizon ussuri example i gave on the ml thread was a fairly heavy exercise of all levels of semver over the course of a cycle, i don't think it created confusion for anyone16:42
ttxright, but you;re afraid of the major number inflation because it "looks bad"16:43
ttxHaving 16.2.0 bumped to 17.0.0 days before final... looks bad?16:43
fungii suppose the concern is that people might be surprised if horizon had branched stable/ussuri at 18.3.0 but then tagged 19.0.0 on stable/ussuri before the ussuri release?16:44
smcginnisNot just looks bad. That we are releasing a major release that could be bad. Someone could pick that up assuming it's something we intend for them to use. Then they see a new major release out, try to upgrade, and we break something that normally we would handle upgrading to better if we considered it a true release before.16:44
smcginnisNo more "quick, we have to fix that before the final release goes out" because every release is the final release.16:44
fungior might not realize 19.0.0 was the ussuri release and thought it was a master branch tag for victoria?16:44
ttxI feel like it's already the case with all our libs though16:45
smcginnisRegardless of branch/series/cycle/whatever.16:45
smcginnisYes, and we make sure we handle things right in libs.16:45
toskyI believe (and then I will shut up about the topic) that having a 18.2.0->19.0.0 bump, leaving out of any release a 18.2.0 version which looks like a stable release but it's not, it is confusing16:45
toskyto me16:45
toskyand it's not about marketing16:45
toskythat's it16:45
smcginnisLess so in services because we've had this gray area window before final RC where we can make changes that may break things we determine we shouldn't have done in the first place.16:46
*** amoralej is now known as amoralej|off16:46
ttxsmcginnis: right... so RCs allows to have things that are "will be a release unless we find better"16:47
smcginnisWe can move on. It's just something I've seen happen that if we change how we do things, teams will need to make sure they are doing things appropriately when running into those kinds of situation.16:47
fungitosky: there was no stable release for horizon 17.x.x at all, did that cause confusion?16:47
ttxwithout doing one just yet?16:47
fungi(horizon train is 16.x.x, horizon ussuri is 18.x.x)16:47
ttxhow about... not doing a release until the very end.16:48
*** ricolin has quit IRC16:48
smcginnisttx: Will be a release but "oh crap, we messed up and didn't realize a kitten dies ever time this happens so we need to quick throw out what we had in there and do something different".16:48
ttxAnd from a process persepctive, we would only require that a change proposing the final release is out there16:48
smcginnisHaving multiple major bumps in a release cycle is not the issue I'm pointing out.16:48
ttxthat allows to do ""release candidates"16:48
ttxyou just don;t tag one, you update the release patch16:49
ttxso you have that patch up that tags nova 17.0.0 at sha foobar16:49
toskyfungi: yes, it is for me; it seems I'm the only one16:49
fungismcginnis: the issue you're pointing out is having major bumps during the stabilization period, right?16:49
ttxyou keep it warm16:49
ttxupdate it to another SHA if you have critical fixes16:49
smcginnisfungi: No. Let's move on though, since I'm the only one that sees this issue.16:50
ttxand we just push at at the very end... same result as RCs, withouthaving to maintain a separate model16:50
fungiyeah, i guess i'm not grasping what you're trying to point out either16:50
ttxI'll explain what I mean in a response to the thread16:50
ttxno need to discuss it now16:51
ttxso question 2 was16:51
ttxShould we really support Rally being a part of OpenStack while being independent from the OpenStack release16:51
ttxRally is the exception16:51
ttxthe one service that is part of openstack but does not follow the cycle16:51
ttxthere used to be more of those, but it's the only one left16:51
ttxI'm not sure we need to have that exception really16:52
ttxYou're either part of openstack or not16:52
smcginnisSolum, storlets, cyborg, karbor, masakaru, monasca-events-api16:52
ttxsmcginnis: false16:52
smcginnisWe have a few services under independent.16:52
ttxthose used to be independent, when they started16:52
ttxbefore inclusion in first release16:52
fungiis rally really still active? i don't ever see any discussions of it on the ml these days, or questions about it for that matter16:52
smcginnisAh, OK. Those are just the historical releases then.16:52
ttxthey all moved to cycle-based16:52
ttxI checked, only Rally is left16:53
ttxKuryr too, but it's a library16:53
ttxlibraries still make sense as cycle-independent, if generally useful16:53
smcginnisWhat is the concern having an independent service?16:53
ttx1/ The messaging is blurry -- it's part of openstack but not part of "openstack"16:54
ttx2/ we have to keep the possibility for services to pick that alternate model, just because one service uses it16:54
ttxso, unnecessary complexity16:54
ttxwhen there were 3 projects in that case I was like... maybe. But now there is only one left I'm like, you should either be a part of the openstack release or not16:55
smcginnisThinking about it - I don't think I've thought enough though to have a strong opinion either way.16:56
ttxThat would be a TC thing anyway... but was wondering if we wanted to raise it or not16:56
ttxI guess we could work around it by calling it a testing tool rather than a service.16:57
smcginnisProbably worth pointing it out to the TC to see what they think.16:57
dhellmannhi, smcginnis :-)16:57
ttxdhellmann: hi! TL;DR: do you remember why we enforce branches to be created at tag points?16:57
ttxThat limits flexibility on when stable branches start16:58
dhellmannI think to start it was just because that's the way we'd always done it? The git history of that part of the release validation might help.16:58
dhellmannI'm sure reno expects that, but we probably already had to work around it so it might be less of a hard requirement now16:59
ttxdhellmann: historically the branches were manually created, so we gave Gerrit a SHA16:59
dhellmannoh, hmm16:59
dhellmannwell then I'm not sure. maybe it had to do with making it easier for folks to enter data in the release repo?16:59
ttxI remember the time when branching and RC1s were different deadlines16:59
ttxdhellmann: could totally be an implementation detail yes17:00
smcginnisWould we need to give reno a starting sha instead of tag to be able to generate release notes without including commits in both branches?17:00
ttxLike we'd ask them to submit branching and RC1s at the same time17:00
dhellmannsmcginnis : yeah, that's what I would be worried about. the logic to find the base of the branch looks for a tag that's on both branches so if there isn't one it pulls in extra history17:01
ttxalso at one point we supported creating RCs for c-w-i deliverables,,, Like swift would do releases but do RCs for the final one. I wonder why we stopped allowing that17:02
dhellmannI don't remember the swift team ever wanting to do that, so I'm not sure about that change either17:03
ttxprobably because that was confusing, but maybe as a single unified model that could work17:03
ttxdhellmann: they did not want it, we forced them to do it17:03
ttxso that they would fit in the coordinated release process17:03
ttxand then we stopped17:03
dhellmannmaybe dropping it was all part of adding the release cycle-with-intermediary stuff then?17:03
ttxyes that's what I think17:04
ttxbut maybe allowing RC tags for those who want it could be a possibility17:04
ttxsolving everyone's fears about it17:04
ttxlike a single model that allows both approaches17:04
ttxok, I'll continue brainstorming on the thread17:05
dhellmannyeah, that might be a reasonable compromise. I wonder how many teams would use them optionally.17:05
fungii feel like most of the extreme objections were based on a misreading of the proposal anyway17:05
dhellmannI got the sense that some people are thinking about the versions of individual projects vs. the final release version set of all of openstack17:05
ttxsmcginnis: we can move on :)17:06
smcginnisIt's a change in something we've been doing for years, so some people are going to be resistant to that anyway.17:06
smcginnis#topic Countdown email17:06
*** openstack changes topic to "Countdown email (Meeting topic: releaseteam)"17:06
ttxdhellmann: yes... like zigo complaining about not being able to tell in the Debian page which one is the final at first glance17:06
ttxI think that's fair17:06
smcginnisPlease take a look and make any edits. I will send it tomorrow.17:06
ttxit /is/ difficult to see which component numbers are part of the coordinated release without looking at releases.o.o17:07
dhellmannttx: I wonder if branching at a tag may have been the way to avoid merging tags from one branch to another?17:07
fungibut we used to merge the release tags back into master, not the rc tags17:08
ttxmaybe... In doubt it's probably simpler to ask that if you want to branch early, you need to tag a beta or RC17:09
dhellmannright, but now we don't do either and at least we have that RC tag to be able to tell where the previous release forked off17:09
ttxsmcginnis: that looks like next week's message17:09
ttxi.e. next week is victoria-1, not the week after17:10
* dhellmann wanders off, but is only a ping away17:10
ttxdhellmann: thanks!17:10
smcginnisThanks dhellmann17:10
smcginnisttx: You're right!17:10
ttxI was like... wow, this week was victoria-1? Time flies! Hmm... wait a minute17:11
smcginnisHmm, I got the subject line right, just not the content.17:11
smcginnisOK, fixed.17:12
smcginnisI will review again before sending just to be safe. ;)17:12
smcginnisI need to get going soon. Anything else for today?17:13
smcginnisThanks everyone.17:14
*** openstack changes topic to "OpenStack Release Managers office - Come here to discuss how to release OpenStack components - Logged at"17:14
openstackMeeting ended Thu Jun 11 17:14:14 2020 UTC.  Information about MeetBot at . (v 0.1.4)17:14
openstackMinutes (text):
hberaudsmcginnis: thanks17:14
elodsmcginnis: the autorelease is very useful for EM perspective, thanks for that! \o/17:15
smcginniselod: Should make it a lot less painful at EM transition time. ;)17:16
elodsmcginnis: I wonder what tool you are using for that. Is it in the releases repo?17:16
smcginniselod: It will be. I've been trying to get a script cleaned up to do both our auto releases that we need throughout the release cycle as well as being able to do things like these stable releases.17:17
elodsmcginnis: exactly :) the upcoming transitions will be much smooth if there will be more frequent releases triggered :]17:17
*** udesale_ has quit IRC17:19
elodsmcginnis: sounds great!17:19
smcginnisWorth a shot to make things smoother. :)17:19
elodI'm also curious how you choose whether to do a minor version bump or not :-o17:21
smcginnisIt's not fully automated. The script is based on our list_unreleased_changes script. So it goes through all deliverables for that series and prints out whatever commits are present that are not included in a release. It prompts if a release should be done, and if so whether it should be a bugfix or feature bump.17:23
smcginnisProbably not a good way to fully automate, but at least it automates enough that it's not too much work to do.17:23
elodI think it helps a lot, so worth to use it!17:25
openstackgerritJulia Kreger proposed openstack/releases master: Release ironic-lib 4.2.1 for ussuri
*** slaweq has joined #openstack-release19:49
*** slaweq has quit IRC20:26
*** slaweq has joined #openstack-release20:31
*** slaweq has quit IRC20:35
rm_workHey so...
rm_workOctavia Ocata/Pike EOL20:38
rm_workde-facto for like... over a year now. would love to get this de jure20:38
smcginnisrm_work: Have you posted this to the ML to announce it going EOL?20:56
rm_workI think you asked this before20:56
rm_workand it was answered before in the comments, though at this point has gotten lost20:56
smcginnisHah, probably. Sorry, it's been awhile.20:57
rm_worknow do :D20:58
rm_workah actually, maybe we will do ONE last queens release20:58
rm_workso I'll sit on this for ... maybe a week20:59
smcginnisWas just looking at that one.20:59
rm_workyeah we'll see if we get the gates working well enough20:59
rm_workif we do, then I'll upload a new EOL patch20:59
rm_workif not, i'll just remove the WIP21:00
smcginnisSounds good.21:00
smcginnisJust to be clear, we can't do a real release. But we can get stuff merged and included before we tag the eol.21:00
openstackgerritMerged openstack/releases master: Octavia: EOL Ocata and Pike
*** jtomasek has quit IRC21:48
*** dustinc has joined #openstack-release21:55
*** jbadiapa has quit IRC22:26
*** tkajinam has joined #openstack-release22:47
*** tosky has quit IRC23:10
openstackgerritMichael Johnson proposed openstack/releases master: Release Octavia stable/ussuri 6.0.1

Generated by 2.17.2 by Marius Gedminas - find it at!