| *** hongbin has quit IRC | 00:16 | |
| *** hongbin has joined #openstack-release | 00:34 | |
| *** hongbin has quit IRC | 01:42 | |
| *** ricolin has joined #openstack-release | 02:39 | |
| *** hongbin has joined #openstack-release | 02:43 | |
| *** tetsuro has quit IRC | 03:16 | |
| *** tetsuro has joined #openstack-release | 03:54 | |
| *** evrardjp has quit IRC | 04:33 | |
| *** hongbin has quit IRC | 04:33 | |
| *** evrardjp has joined #openstack-release | 04:33 | |
| *** ykarel|away is now known as ykarel | 04:37 | |
| *** vishalmanchanda has joined #openstack-release | 05:35 | |
| *** tetsuro_ has joined #openstack-release | 05:45 | |
| *** tetsuro__ has joined #openstack-release | 05:47 | |
| *** tetsuro has quit IRC | 05:47 | |
| *** tetsuro_ has quit IRC | 05:50 | |
| *** udesale has joined #openstack-release | 06:02 | |
| *** udesale has quit IRC | 06:17 | |
| *** udesale has joined #openstack-release | 06:18 | |
| *** jbadiapa has quit IRC | 06:23 | |
| *** jbadiapa has joined #openstack-release | 06:30 | |
| *** dustinc has quit IRC | 06:35 | |
| *** rpittau|afk is now known as rpittau | 07:18 | |
| *** amoralej|off is now known as amoralej | 07:25 | |
| *** tetsuro__ has quit IRC | 07:37 | |
| *** tosky has joined #openstack-release | 07:38 | |
| *** tetsuro has joined #openstack-release | 07:40 | |
| *** ykarel is now known as ykarel|lunch | 07:53 | |
| *** slaweq has quit IRC | 08:15 | |
| *** slaweq has joined #openstack-release | 08:20 | |
| *** e0ne has joined #openstack-release | 08:20 | |
| *** ykarel|lunch is now known as ykarel | 08:56 | |
| *** tetsuro has quit IRC | 08:57 | |
| *** tetsuro has joined #openstack-release | 09:00 | |
| *** rpittau is now known as rpittau|bbl | 09:15 | |
| *** slaweq has quit IRC | 09:19 | |
| *** e0ne_ has joined #openstack-release | 09:20 | |
| *** e0ne has quit IRC | 09:20 | |
| *** e0ne has joined #openstack-release | 09:28 | |
| *** tetsuro has quit IRC | 09:28 | |
| *** e0ne_ has quit IRC | 09:28 | |
| *** slaweq has joined #openstack-release | 09:57 | |
| openstackgerrit | Merged openstack/releases master: release oslo.utils 4.2.1 https://review.opendev.org/734844 | 09:59 |
|---|---|---|
| openstackgerrit | Merged openstack/releases master: Release horizon 16.2.0 (train) https://review.opendev.org/734163 | 10:03 |
| *** slaweq has quit IRC | 10:20 | |
| *** slaweq has joined #openstack-release | 10:26 | |
| *** slaweq has quit IRC | 10:30 | |
| *** ricolin has quit IRC | 10:47 | |
| *** slaweq has joined #openstack-release | 11:24 | |
| *** rpittau|bbl is now known as rpittau | 11:54 | |
| *** amoralej is now known as amoralej|off | 12:08 | |
| *** amoralej|off is now known as amoralej|lunch | 12:08 | |
| *** slaweq has quit IRC | 12:13 | |
| *** slaweq has joined #openstack-release | 12:13 | |
| *** slaweq has quit IRC | 12:18 | |
| *** tkajinam has quit IRC | 12:25 | |
| *** mnaser has quit IRC | 12:32 | |
| *** gmann has quit IRC | 12:33 | |
| *** nicolasbock has quit IRC | 12:33 | |
| *** nicolasbock has joined #openstack-release | 12:33 | |
| *** gmann has joined #openstack-release | 12:33 | |
| *** mnaser has joined #openstack-release | 12:33 | |
| *** slaweq has joined #openstack-release | 12:43 | |
| *** slaweq has quit IRC | 12:47 | |
| *** ykarel is now known as ykarel|afk | 13:00 | |
| *** amoralej|lunch is now known as amoralej | 13:13 | |
| *** ricolin has joined #openstack-release | 13:51 | |
| *** ykarel|afk is now known as ykarel | 13:57 | |
| *** udesale_ has joined #openstack-release | 14:19 | |
| *** udesale has quit IRC | 14:22 | |
| *** slaweq has joined #openstack-release | 14:52 | |
| *** slaweq has quit IRC | 15:20 | |
| *** slaweq has joined #openstack-release | 15:25 | |
| *** ykarel is now known as ykarel|away | 15:27 | |
| *** slaweq has quit IRC | 15:30 | |
| ttx | smcginnis: propose we start the release meeting once the board meeting ends, which might be a few minutes late | 15:39 |
| smcginnis | ttx: I was thinking the same thing. | 15:43 |
| *** e0ne has quit IRC | 15:48 | |
| *** e0ne has joined #openstack-release | 15:49 | |
| *** rpittau is now known as rpittau|afk | 15:58 | |
| *** vishalmanchanda has quit IRC | 16:00 | |
| smcginnis | ttx: I had dropped earlier. Is the board meeting still going on? | 16:03 |
| fungi | it went into executive session | 16:06 |
| smcginnis | OK | 16:06 |
| fungi | i don't know if there was going to be another open session thereafter, but seemed like not | 16:06 |
| *** dhellmann_ has joined #openstack-release | 16:10 | |
| *** dhellmann has quit IRC | 16:11 | |
| *** dhellmann_ is now known as dhellmann | 16:11 | |
| ttx | o/ | 16:18 |
| smcginnis | #startmeeting releaseteam | 16:18 |
| openstack | Meeting 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 http://wiki.debian.org/MeetBot. | 16:18 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:18 |
| *** openstack changes topic to " (Meeting topic: releaseteam)" | 16:18 | |
| openstack | The meeting name has been set to 'releaseteam' | 16:18 |
| smcginnis | Reminder to folks to add you nicks to the ping list in the new etherpad if you want that. | 16:19 |
| smcginnis | #link https://etherpad.opendev.org/p/victoria-relmgt-tracking Agenda | 16:19 |
| smcginnis | Well, 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 completion | 16:21 |
| *** openstack changes topic to "Review task completion (Meeting topic: releaseteam)" | 16:21 | |
| smcginnis | Taks for this week was to get the list of cycle-trailing deliverables for ussuri. | 16:21 |
| smcginnis | That 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 |
| smcginnis | But I did run that and sent a post to the ML reminding those teams that it will need to be done. | 16:22 |
| ttx | I think a reminder is always good | 16:22 |
| ttx | well ahead of the deadline | 16:22 |
| hberaud | o/ | 16:22 |
| smcginnis | Doesn't hurt. I think it did trigger at least one team to do a release. | 16:22 |
| ttx | I 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 |
| smcginnis | I was planning on bringing that up. | 16:23 |
| smcginnis | I did that partly with my stable hat on. | 16:23 |
| smcginnis | Partly 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 |
| smcginnis | I 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 |
| smcginnis | When 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 |
| ttx | ok, if we can get the cost near zero | 16:24 |
| smcginnis | Rather than doing that regularly over the course of the stable branch lifecycle. | 16:24 |
| ttx | What's costly generally is to handle the ones who do not get +1 | 16:24 |
| smcginnis | And 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 |
| fungi | released 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 |
| ttx | so maybe we should decide what to do with those ahead of time | 16:25 |
| smcginnis | ttx: 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 |
| ttx | fungi: it would not be on the release schedule, just in the team process timeline | 16:25 |
| fungi | right, i figured | 16:25 |
| smcginnis | I'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 |
| smcginnis | fungi: Yep. | 16:26 |
| fungi | but 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 |
| ttx | ok, 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 |
| smcginnis | I thought it would be a good quieter week to get something like that out. | 16:26 |
| smcginnis | I'll go through and abandon any that get no response next week. | 16:26 |
| ttx | I just don;t want to get the impression that they need to wait for us to propose it to get a stable release out | 16:26 |
| smcginnis | True | 16:26 |
| ttx | but I guess that can be worded in the commit message | 16:27 |
| smcginnis | Maybe next time I should add more clarification to the commit message. | 16:27 |
| ttx | +1 | 16:27 |
| smcginnis | Anyway, 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 |
| fungi | something which reminds them they really should have been proposing releases sooner on their own | 16:28 |
| smcginnis | Probably 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 |
| ttx | yeah, maybe not say "release team" | 16:29 |
| smcginnis | Part 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 |
| smcginnis | ++ | 16:29 |
| ttx | ok next | 16:29 |
| smcginnis | I'll try to be more clear next time. | 16:29 |
| smcginnis | topic Review next week's tasks | 16:29 |
| smcginnis | We have the c-w-i lib releases. | 16:30 |
| ttx | woohoo | 16:30 |
| smcginnis | That ties in well to testing out this scripting I've been doing, so I'd like to take that one. | 16:30 |
| ttx | permission granted | 16:30 |
| hberaud | :) | 16:30 |
| smcginnis | :) | 16:30 |
| smcginnis | Next, ACL issues. | 16:30 |
| ttx | I can take the acl unless someone wants it | 16:30 |
| hberaud | not sure what's behind | 16:31 |
| smcginnis | ttx: I think you've become the de facto ACL man. :) | 16:31 |
| smcginnis | Maybe a chance to walk through it with hberaud? | 16:31 |
| ttx | I have a few other consistency work I've been pushing | 16:31 |
| hberaud | +1 | 16:31 |
| ttx | sure | 16:31 |
| smcginnis | And I'll send the countdown email. | 16:32 |
| smcginnis | #topic One release model to bind them all - open questions | 16:32 |
| *** openstack changes topic to "One release model to bind them all - open questions (Meeting topic: releaseteam)" | 16:32 | |
| ttx | right, so the discussion opened a couple of questions | 16:32 |
| ttx | first one is... | 16:32 |
| ttx | Can 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 |
| ttx | Currently we enforce that the branch point is at a tag, for most deliverables | 16:33 |
| ttx | I'm.. not sure where that came from | 16:33 |
| smcginnis | Our validation prevents that right now, but we can change it. We do that for non-cycle based things. | 16:33 |
| ttx | historically we did manually create branches from arbitrary commits, on demand | 16:33 |
| smcginnis | We allow it for things like feature branches, but enforce that tagging with stable branches. | 16:33 |
| ttx | that allowed stable work to start before the RC release itself | 16:33 |
| smcginnis | Not really sure the background on that either. | 16:34 |
| ttx | well feature branches should obviously not require to start from a tag | 16:34 |
| smcginnis | We 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 |
| fungi | not having a tag there does make it harder for downstream consumers to try out the candidate though | 16:34 |
| ttx | OK, if that does not ring a bell, I'll try to find where that requirement came from | 16:34 |
| ttx | it might just be taht it started that way and was cargoculted | 16:35 |
| smcginnis | Pretty sure it was from before my time, so that may take some digging. | 16:35 |
| smcginnis | Could be. | 16:35 |
| ttx | At first glance i can;t see why that would be necessary | 16:35 |
| smcginnis | Release note generation? | 16:36 |
| ttx | hmm | 16:36 |
| fungi | for testing purposes, it may still be that you'd want to encourage most projects to branch from an initial tag anyway | 16:36 |
| ttx | I'll ask dhellmann if that rings a bell for him | 16:36 |
| fungi | and branching from an arbitrary commit in master would be an exception rather than commonplace | 16:37 |
| ttx | anyway, allowing it now would give a bit more flexibility | 16:37 |
| ttx | so you can start the stabilization work slightly ahead of when you think you have a great release candidate | 16:38 |
| ttx | Most of the reaction on that thread seems to be around confusing marketing release numbers and semver numbers | 16:39 |
| ttx | Like a release should be x.0.0! | 16:39 |
| smcginnis | It 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 |
| ttx | I'd say that finally letting go of marketing numbers is a good thing | 16:40 |
| ttx | especially since half the openstack world has already moved on | 16:40 |
| ttx | ok, second question... | 16:41 |
| smcginnis | I'm a little concerned about the corner case I pointed out earlier today. Occasionally breaking changes have been merged between RCs. | 16:41 |
| smcginnis | And two major version bumps within a short timeframe could be a little confusing. | 16:41 |
| ttx | oh you mean respecting semver in prereleases | 16:41 |
| ttx | release number inflation around pre-releases | 16:42 |
| smcginnis | Yeah. | 16:42 |
| ttx | It's another case of conflating marketing and semver numbers | 16:42 |
| smcginnis | That's just semver. | 16:42 |
| smcginnis | No marketing involved. | 16:42 |
| fungi | the 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 anyone | 16:42 |
| ttx | right, but you;re afraid of the major number inflation because it "looks bad" | 16:43 |
| ttx | Having 16.2.0 bumped to 17.0.0 days before final... looks bad? | 16:43 |
| fungi | i 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 |
| smcginnis | Not 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 |
| smcginnis | No more "quick, we have to fix that before the final release goes out" because every release is the final release. | 16:44 |
| fungi | or might not realize 19.0.0 was the ussuri release and thought it was a master branch tag for victoria? | 16:44 |
| ttx | I feel like it's already the case with all our libs though | 16:45 |
| smcginnis | Regardless of branch/series/cycle/whatever. | 16:45 |
| smcginnis | Yes, and we make sure we handle things right in libs. | 16:45 |
| tosky | I 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 confusing | 16:45 |
| tosky | to me | 16:45 |
| tosky | and it's not about marketing | 16:45 |
| tosky | that's it | 16:45 |
| smcginnis | Less 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|off | 16:46 | |
| ttx | smcginnis: right... so RCs allows to have things that are "will be a release unless we find better" | 16:47 |
| smcginnis | We 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 |
| fungi | tosky: there was no stable release for horizon 17.x.x at all, did that cause confusion? | 16:47 |
| ttx | without doing one just yet? | 16:47 |
| fungi | (horizon train is 16.x.x, horizon ussuri is 18.x.x) | 16:47 |
| ttx | how about... not doing a release until the very end. | 16:48 |
| *** ricolin has quit IRC | 16:48 | |
| smcginnis | ttx: 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 |
| ttx | And from a process persepctive, we would only require that a change proposing the final release is out there | 16:48 |
| smcginnis | Having multiple major bumps in a release cycle is not the issue I'm pointing out. | 16:48 |
| ttx | that allows to do ""release candidates" | 16:48 |
| ttx | you just don;t tag one, you update the release patch | 16:49 |
| ttx | so you have that patch up that tags nova 17.0.0 at sha foobar | 16:49 |
| tosky | fungi: yes, it is for me; it seems I'm the only one | 16:49 |
| fungi | smcginnis: the issue you're pointing out is having major bumps during the stabilization period, right? | 16:49 |
| ttx | you keep it warm | 16:49 |
| ttx | update it to another SHA if you have critical fixes | 16:49 |
| smcginnis | fungi: No. Let's move on though, since I'm the only one that sees this issue. | 16:50 |
| ttx | and we just push at at the very end... same result as RCs, withouthaving to maintain a separate model | 16:50 |
| fungi | yeah, i guess i'm not grasping what you're trying to point out either | 16:50 |
| ttx | I'll explain what I mean in a response to the thread | 16:50 |
| ttx | no need to discuss it now | 16:51 |
| ttx | so question 2 was | 16:51 |
| ttx | Should we really support Rally being a part of OpenStack while being independent from the OpenStack release | 16:51 |
| ttx | Rally is the exception | 16:51 |
| ttx | the one service that is part of openstack but does not follow the cycle | 16:51 |
| ttx | there used to be more of those, but it's the only one left | 16:51 |
| ttx | I'm not sure we need to have that exception really | 16:52 |
| ttx | You're either part of openstack or not | 16:52 |
| smcginnis | Solum, storlets, cyborg, karbor, masakaru, monasca-events-api | 16:52 |
| ttx | smcginnis: false | 16:52 |
| smcginnis | kuyryr-libnetworl | 16:52 |
| smcginnis | We have a few services under independent. | 16:52 |
| ttx | those used to be independent, when they started | 16:52 |
| ttx | before inclusion in first release | 16:52 |
| fungi | is rally really still active? i don't ever see any discussions of it on the ml these days, or questions about it for that matter | 16:52 |
| smcginnis | Ah, OK. Those are just the historical releases then. | 16:52 |
| ttx | they all moved to cycle-based | 16:52 |
| ttx | I checked, only Rally is left | 16:53 |
| ttx | Kuryr too, but it's a library | 16:53 |
| ttx | libraries still make sense as cycle-independent, if generally useful | 16:53 |
| smcginnis | What is the concern having an independent service? | 16:53 |
| ttx | 1/ The messaging is blurry -- it's part of openstack but not part of "openstack" | 16:54 |
| ttx | 2/ we have to keep the possibility for services to pick that alternate model, just because one service uses it | 16:54 |
| ttx | so, unnecessary complexity | 16:54 |
| ttx | when 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 not | 16:55 |
| smcginnis | Thinking about it - I don't think I've thought enough though to have a strong opinion either way. | 16:56 |
| ttx | That would be a TC thing anyway... but was wondering if we wanted to raise it or not | 16:56 |
| ttx | I guess we could work around it by calling it a testing tool rather than a service. | 16:57 |
| smcginnis | Probably worth pointing it out to the TC to see what they think. | 16:57 |
| dhellmann | o/ | 16:57 |
| smcginnis | dhellmann! | 16:57 |
| dhellmann | hi, smcginnis :-) | 16:57 |
| ttx | dhellmann: hi! TL;DR: do you remember why we enforce branches to be created at tag points? | 16:57 |
| ttx | That limits flexibility on when stable branches start | 16:58 |
| dhellmann | I 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 |
| dhellmann | I'm sure reno expects that, but we probably already had to work around it so it might be less of a hard requirement now | 16:59 |
| ttx | dhellmann: historically the branches were manually created, so we gave Gerrit a SHA | 16:59 |
| dhellmann | oh, hmm | 16:59 |
| dhellmann | well 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 |
| ttx | I remember the time when branching and RC1s were different deadlines | 16:59 |
| ttx | dhellmann: could totally be an implementation detail yes | 17:00 |
| smcginnis | Would 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 |
| ttx | Like we'd ask them to submit branching and RC1s at the same time | 17:00 |
| dhellmann | smcginnis : 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 history | 17:01 |
| ttx | also 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 that | 17:02 |
| dhellmann | I don't remember the swift team ever wanting to do that, so I'm not sure about that change either | 17:03 |
| ttx | probably because that was confusing, but maybe as a single unified model that could work | 17:03 |
| ttx | dhellmann: they did not want it, we forced them to do it | 17:03 |
| ttx | so that they would fit in the coordinated release process | 17:03 |
| ttx | and then we stopped | 17:03 |
| dhellmann | maybe dropping it was all part of adding the release cycle-with-intermediary stuff then? | 17:03 |
| ttx | yes that's what I think | 17:04 |
| ttx | but maybe allowing RC tags for those who want it could be a possibility | 17:04 |
| ttx | solving everyone's fears about it | 17:04 |
| ttx | like a single model that allows both approaches | 17:04 |
| ttx | ok, I'll continue brainstorming on the thread | 17:05 |
| dhellmann | yeah, that might be a reasonable compromise. I wonder how many teams would use them optionally. | 17:05 |
| fungi | i feel like most of the extreme objections were based on a misreading of the proposal anyway | 17:05 |
| dhellmann | I got the sense that some people are thinking about the versions of individual projects vs. the final release version set of all of openstack | 17:05 |
| ttx | smcginnis: we can move on :) | 17:06 |
| smcginnis | It'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 email | 17:06 |
| *** openstack changes topic to "Countdown email (Meeting topic: releaseteam)" | 17:06 | |
| ttx | dhellmann: yes... like zigo complaining about not being able to tell in the Debian page which one is the final at first glance | 17:06 |
| smcginnis | #link https://etherpad.opendev.org/p/relmgmt-weekly-emails | 17:06 |
| ttx | I think that's fair | 17:06 |
| smcginnis | Please take a look and make any edits. I will send it tomorrow. | 17:06 |
| hberaud | LGTM | 17:07 |
| ttx | it /is/ difficult to see which component numbers are part of the coordinated release without looking at releases.o.o | 17:07 |
| dhellmann | ttx: I wonder if branching at a tag may have been the way to avoid merging tags from one branch to another? | 17:07 |
| fungi | but we used to merge the release tags back into master, not the rc tags | 17:08 |
| ttx | maybe... In doubt it's probably simpler to ask that if you want to branch early, you need to tag a beta or RC | 17:09 |
| dhellmann | right, 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 off | 17:09 |
| ttx | smcginnis: that looks like next week's message | 17:09 |
| ttx | i.e. next week is victoria-1, not the week after | 17:10 |
| * dhellmann wanders off, but is only a ping away | 17:10 | |
| ttx | dhellmann: thanks! | 17:10 |
| smcginnis | Thanks dhellmann | 17:10 |
| smcginnis | ttx: You're right! | 17:10 |
| ttx | I was like... wow, this week was victoria-1? Time flies! Hmm... wait a minute | 17:11 |
| smcginnis | Hmm, I got the subject line right, just not the content. | 17:11 |
| smcginnis | OK, fixed. | 17:12 |
| smcginnis | I will review again before sending just to be safe. ;) | 17:12 |
| smcginnis | I need to get going soon. Anything else for today? | 17:13 |
| ttx | nope | 17:14 |
| ttx | endmeeting! | 17:14 |
| hberaud | nope | 17:14 |
| smcginnis | Thanks everyone. | 17:14 |
| smcginnis | #endmeeting | 17:14 |
| *** openstack changes topic to "OpenStack Release Managers office - Come here to discuss how to release OpenStack components - Logged at http://eavesdrop.openstack.org/irclogs/%23openstack-release/" | 17:14 | |
| openstack | Meeting ended Thu Jun 11 17:14:14 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:14 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/releaseteam/2020/releaseteam.2020-06-11-16.18.html | 17:14 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/releaseteam/2020/releaseteam.2020-06-11-16.18.txt | 17:14 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/releaseteam/2020/releaseteam.2020-06-11-16.18.log.html | 17:14 |
| hberaud | smcginnis: thanks | 17:14 |
| elod | smcginnis: the autorelease is very useful for EM perspective, thanks for that! \o/ | 17:15 |
| smcginnis | elod: Should make it a lot less painful at EM transition time. ;) | 17:16 |
| elod | smcginnis: I wonder what tool you are using for that. Is it in the releases repo? | 17:16 |
| smcginnis | elod: 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 |
| elod | smcginnis: exactly :) the upcoming transitions will be much smooth if there will be more frequent releases triggered :] | 17:17 |
| *** udesale_ has quit IRC | 17:19 | |
| elod | smcginnis: sounds great! | 17:19 |
| smcginnis | Worth a shot to make things smoother. :) | 17:19 |
| elod | :) | 17:20 |
| elod | I'm also curious how you choose whether to do a minor version bump or not :-o | 17:21 |
| smcginnis | It'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 |
| smcginnis | Probably not a good way to fully automate, but at least it automates enough that it's not too much work to do. | 17:23 |
| elod | I think it helps a lot, so worth to use it! | 17:25 |
| openstackgerrit | Julia Kreger proposed openstack/releases master: Release ironic-lib 4.2.1 for ussuri https://review.opendev.org/735213 | 18:50 |
| *** slaweq has joined #openstack-release | 19:49 | |
| *** slaweq has quit IRC | 20:26 | |
| *** slaweq has joined #openstack-release | 20:31 | |
| *** slaweq has quit IRC | 20:35 | |
| rm_work | Hey so... https://review.opendev.org/#/c/719097/1 | 20:37 |
| rm_work | :) | 20:37 |
| rm_work | Octavia Ocata/Pike EOL | 20:38 |
| rm_work | de-facto for like... over a year now. would love to get this de jure | 20:38 |
| smcginnis | rm_work: Have you posted this to the ML to announce it going EOL? | 20:56 |
| rm_work | yes | 20:56 |
| rm_work | I think you asked this before | 20:56 |
| rm_work | and it was answered before in the comments, though at this point has gotten lost | 20:56 |
| smcginnis | Hah, probably. Sorry, it's been awhile. | 20:57 |
| rm_work | thanks! | 20:58 |
| rm_work | now do https://review.opendev.org/#/c/719099/ :D | 20:58 |
| rm_work | ah actually, maybe we will do ONE last queens release | 20:58 |
| rm_work | so I'll sit on this for ... maybe a week | 20:59 |
| smcginnis | Was just looking at that one. | 20:59 |
| rm_work | yeah we'll see if we get the gates working well enough | 20:59 |
| rm_work | if we do, then I'll upload a new EOL patch | 20:59 |
| rm_work | if not, i'll just remove the WIP | 21:00 |
| smcginnis | Sounds good. | 21:00 |
| smcginnis | Just 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 |
| openstackgerrit | Merged openstack/releases master: Octavia: EOL Ocata and Pike https://review.opendev.org/719097 | 21:07 |
| *** jtomasek has quit IRC | 21:48 | |
| *** dustinc has joined #openstack-release | 21:55 | |
| *** jbadiapa has quit IRC | 22:26 | |
| *** tkajinam has joined #openstack-release | 22:47 | |
| *** tosky has quit IRC | 23:10 | |
| openstackgerrit | Michael Johnson proposed openstack/releases master: Release Octavia stable/ussuri 6.0.1 https://review.opendev.org/735266 | 23:43 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!