19:00:17 <tonyb> #startmeeting releaseteam
19:00:18 <openstack> Meeting started Thu Aug  1 19:00:17 2019 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:21 <openstack> The meeting name has been set to 'releaseteam'
19:00:25 <smcginnis> o/
19:00:33 <ttx> i did push a full agenda for today :)
19:00:47 <tonyb> ttx: Thanks
19:01:02 <diablo_rojo> o/
19:01:07 <armstrong> o/
19:01:28 <tonyb> diablo_rojo, armstrong: Hello
19:01:46 <smcginnis> How's we get so far down in that tracking etherpad already?
19:01:51 <smcginnis> *How'd
19:01:58 <ttx> R-11 it is
19:02:12 <fungi> i never can remember the agenda url
19:02:17 <ttx> https://etherpad.openstack.org/p/train-relmgt-tracking
19:02:30 <ttx> scroll down to ~277
19:02:34 <fungi> thank! would be awesome if it were just mentioned at the start of each meeting
19:02:44 <tonyb> fungi: I only know it because it's perma-open
19:02:57 <fungi> heh
19:02:58 <ttx> I trained my firefox to remember it for me
19:03:19 <fungi> yeah, i typically find it by starting to type some stuff into the url bar and see what comes up
19:03:30 <fungi> (i suppose i should really use bookmarks)
19:03:44 <ttx> shall we start?
19:03:53 <tonyb> Yup
19:04:07 <dhellmann> cranky email response sent to the thread about release models
19:04:21 <dhellmann> oh, hi :-)
19:04:27 <tonyb> #topic Late train-2 milestone actions
19:04:34 <ttx> So I did recompile the list of libraries that were not refreshed since milestone-1, and looked up the recent changes
19:04:44 <ttx> Result at https://etherpad.openstack.org/p/train-2-library-autoreleases
19:04:52 <ttx> with the likely candidates in bold
19:05:04 <ttx> In theory we should propose a release for all of those
19:05:49 <ttx> Any objection? Any volunteer to push those?
19:06:11 <diablo_rojo> dhellmann, several cranky responses, lots of shooting the messenger
19:06:29 <dhellmann> diablo_rojo : I meant my own cranky response :-)
19:06:46 <diablo_rojo> dhellmann, ah I have only seen the three previous ones
19:06:49 <dhellmann> ttx: when you say "all" do you mean the bolded ones, or all of them?
19:06:49 <tonyb> ttx: Sounds good to me.  I was on my todo list for this week but it hasn't happened
19:06:54 <ttx> bolded
19:07:00 <dhellmann> ok, no objection
19:07:08 <ttx> We now just need someone to push those
19:07:16 <ttx> 18
19:07:34 <tonyb> I'll do them (my) tomorrow.
19:07:46 <ttx> thanks!
19:07:53 <fungi> a.k.a. "saturday"
19:07:58 <tonyb> I have arranged to work this weekend to catch up on some of the community work I have dropped
19:08:05 <ttx> Next we have any leftover from the membershipfreeze list
19:08:06 <tonyb> 2 days isn't enough but it will help
19:08:19 <fungi> tonyb: that sucks, you deserve a weekend
19:08:33 <ttx> it seems we still have a few misses
19:08:36 <tonyb> fungi: I agree but ....
19:08:40 <ttx> Like python-adjutantclient
19:08:58 <diablo_rojo> ttx, yeah I tried to ping them again when they didn't address that one but have had no response
19:09:05 <diablo_rojo> I can ping again.
19:09:24 <ttx> It feels like we can propose its addition. Can't have adjutant without python-adjutantclient
19:09:29 <smcginnis> Seems like we should have a probationary period for newly accepted projects. Adjutant had more activity before it was accepted than after.
19:09:29 <ttx> cyborg-tempest-plugin
19:09:33 <ttx> same for ^
19:09:45 <ttx> smcginnis: thatis not our call
19:09:54 <ttx> but we can raise it to the TC yes
19:09:55 <smcginnis> Yeah, just musing.
19:10:12 <diablo_rojo> Also no response.. despite email and attempts at direct pings
19:10:26 <tonyb> Can one of y'all take it to the TC.
19:10:44 <ttx> sure can do
19:10:52 <ttx> what about the ironic ones?
19:11:28 * ttx checks if they are not done already
19:12:21 <ttx> networking-generic-switch-tempest-plugin needs to be made release-management: none
19:13:32 <diablo_rojo> No that one didn't get proposed yet lastI checked
19:13:35 <tonyb> I don't know about ironic
19:13:36 <smcginnis> Shouldn't the tempest plugins just be auto? Or are these ones that declared otherwise?
19:13:56 <ttx> smcginnis: yeah...
19:14:05 <tonyb> I think tempest-plugins shoudl just be auto
19:14:42 <diablo_rojo> TheJulia, agreed the ironic one should be none, there just hasn't been a patch yet.
19:15:06 <ttx> ok, feels like we need to do a number of follow-ups, but I don't want to spend all the meeting on that
19:15:07 <tonyb> Well we can make the patch
19:15:32 <ttx> OSH is a non-issue since they are not train material anyway
19:15:42 <ttx> puppet-crane was, I think, retied?
19:15:45 <ttx> retired
19:16:23 <tonyb> ttx: yup it did
19:17:00 <ttx> instack-undercloud and tripleo-common-tempest-plugin we'll need to doublecheck and propose in case that was not done already
19:17:10 <ttx> That leaves compute-hyperv
19:17:18 <ttx> which I suspect gave no update
19:17:37 <tonyb> I think instack-undecloud is deprecated if not retired
19:18:02 <fungi> that grey area where stable branches are still maintained but development on master has ceased
19:18:13 <tonyb> Ahhh yeah right
19:18:29 <ttx> we have a "deprecated" mention for that case
19:18:42 <ttx> release-management:deprecated
19:18:46 <ttx> in the governance file
19:19:04 <fungi> yeah, they stopped development before stein released
19:19:29 <fungi> (or as of rocky at any rate_
19:19:51 <ttx> That leaves kolla-cli and compute-hyperv as unknowns
19:20:01 <ttx> (if we propose all the others)
19:20:30 <ttx> I'll take the action of proposing all those we have "let's propose it" on
19:20:42 <tonyb> ttx: Thanks
19:20:52 <ttx> If someone can take the action of reaching out (again) to kolla and winstackers
19:20:57 <diablo_rojo> ttx, I can try to poke those two again
19:21:04 <ttx> I don;t think we should propsoe those
19:21:10 <ttx> unless they want it
19:21:35 <ttx> OK, last item on those late things... ACL
19:21:46 <ttx> I did push     https://review.opendev.org/673988 to fix compute-hyperv
19:21:53 <ttx> Kayobe will also need an update but that is better done after it's been renamed. Scheduled for R-8 week
19:22:01 <ttx> that was the only two that needed adjustment
19:22:13 <diablo_rojo> Not so bad
19:22:37 <ttx> diablo_rojo: basically only affects things that were unofficial and become official
19:22:46 <ttx> then we have to fix the ACL
19:23:00 <ttx> OK that was all
19:23:49 <smcginnis> Out of curiosity, what's the new name for kayobe?
19:23:59 <ttx> kayobe.
19:24:10 <ttx> x/kayobe -> openstack/kayobe
19:24:18 <smcginnis> Ah, gotcha.
19:24:25 <ttx> tonyb: next topic?
19:24:49 <tonyb> #topic Should we be OK with cycle-with-intermediary doing only one late release (dtantsur's thread)
19:24:50 * ttx catches up on the therad
19:25:37 <smcginnis> The reason we moved away from that was avoiding finding out at the very end that there's been no release and the current state of the repo is broken, if I remember correct.
19:25:43 * tonyb will make do with the summary
19:25:57 <ttx> yeah, dhellmann can you summarize?
19:26:25 <dhellmann> I gave the reasoning in http://lists.openstack.org/pipermail/openstack-discuss/2019-August/008177.html
19:26:45 <dhellmann> basically, we need a good release to use to create their stable branch
19:26:46 <ttx> 16:54 <ttx> There are two ways to look at the issue
19:26:48 <ttx> 16:55 <ttx> 1/ we propose the model change as a way to open the discussion, to avoid late model changes. Releasing a single intermediary release per cycle is still considered ok
19:26:50 <ttx> 16:55 <ttx> 2/ cycle-with-intermediary requires at least two releases, so we need something up around milestone-2 or we need to switch the model
19:27:14 <dhellmann> and we can get a good release for that by either them letting us release for them (change models) or them releasing now
19:27:24 <ttx> I guess the key question is... are we ok with cycle-with-intermediary things being released only once
19:27:39 <dhellmann> I don't think it's safe to do, no
19:27:47 <diablo_rojo> dhellmann, thank you for your reply to the thread I appreciate you defending the messenger.
19:27:58 <smcginnis> There's also the question of cycle-automatic releasing more than once.
19:28:30 <ttx> smcginnis: I would be OK with that, but I fail to understand the use case
19:28:38 <smcginnis> Yeah...
19:28:54 <ttx> smcginnis: cycle-automatic is for things that are not relally released, just happen to need one per cycle at the end
19:29:19 <ttx> so if they do a feature release of their tempest plugin we have a mismatch
19:29:23 <dhellmann> yeah, the point of describing and naming these models is to clearly differentiate them from each other. If we've missed a case, that's fine. But "I want to be called X but act like Y" isn't a good plan.
19:30:52 <ttx> basically, he hates cycle-with-rcs and would not like falling into it just because he has nothing to release
19:31:10 <ttx> which I can understand
19:31:36 <ttx> cycle-with-rcs is good when you know you only want one
19:31:48 <ttx> cycle-with-intermeidary is good when you know you have 2+
19:31:56 <ttx> but when you have no idea...
19:32:09 <fungi> would a better approach be to have him describe the release model he wants and then we can explain which parts aren't reasonable/logistical?
19:32:26 <fungi> at which point it likely reduces to an existing release model already defined
19:32:28 <ttx> fungi: I think that would be cycle-with-whatever-happens
19:32:44 <fungi> that sounds like independent to me
19:33:04 <dhellmann> fungi : not quite, because independent isn't part of the openstack release
19:33:06 <ttx> no, still want a stable branch at the end tied to the release
19:33:30 <ttx> To be fair, in the recent past we allowed cycle-with-only-one-intermediary
19:34:02 <ttx> the reason why we reinforced the "must have at least 2" requirement was to force some freshness and have a better fallback
19:34:43 <dhellmann> I thought the deliverable where we had that issue with branching incorrectly belonged to the ironic team, but maybe it was tripleo
19:34:52 <dhellmann> maybe it was both of them
19:35:00 <fungi> it's happened several times with tripleo deliverables
19:35:08 <tonyb> yeah
19:35:28 <ttx> I think it's fair that they would not know in advance how many releases will be needed
19:35:53 <ttx> what would be the issue with saying intermediary is 1+
19:36:03 <fungi> but it's also fine to have some point releases on master at arbitrary points in the cycle that cover whatever commits happen to be new
19:36:11 <ttx> (we had the case with swift last cycle when they did only one)
19:36:17 <dhellmann> if they get to the end of the cycle and miss the deadline, would we just not branch them?
19:36:45 <tonyb> We have explained the reasons and the consequences and IIUC the majority of them will be faced by the ironic team so I'm inclined let them go with one
19:37:04 <ttx> dhellmann: we do the same for cycle-with-rcs to get a RC1
19:37:20 <smcginnis> We used to force a final release if none was done. But it was at the end during the crunch, so that wasn't fun.
19:38:17 <ttx> We could autorelease when we need a thing. Like I said earlier, my main issue with that is that it would become the convenience, and teams would no longer "own" their releases
19:38:35 <dhellmann> I want us to avoid getting into a situation where something automated has done the wrong thing. If we can avoid that, then I don't care if projects don't actually do releases until the very end of the cycle.
19:38:53 <dhellmann> Lots of them already don't pay much attention to that part of the process
19:39:21 <ttx> the deliverables where you have no idea how many releases you will do are the sames you probably would not mind being autoreleased
19:39:40 <dhellmann> You'd think. Except the ironic team is the one objecting.
19:39:58 <dhellmann> anyway, I don't know how much my vote on this should really count, so I'll accept what the group decides
19:40:07 <ttx> Here would be my proposal
19:40:26 <fungi> especially problematic if something automatic has done a wrong and undoable thing
19:40:28 <ttx> between milestone2 and milestone3 we look up intermediary things that have not done a release yet.
19:40:36 <fungi> er, wrong and not-undoable
19:40:46 <ttx> We propose a switch to cycle-with-rcs, and use that to start a discussion
19:40:58 <ttx> at that point three things can happen
19:41:14 <ttx> (1) you realize you could do a release, and do one now
19:41:35 <ttx> (2) you realize you only want to do one release this cycle, and +1 the patch
19:42:01 <ttx> (3) you have no idea where you're going and would like to release as-needed, and -1 the patch
19:42:20 <ttx> In the case of (3), if by RC1 freeze we still have no release, we'd force one
19:42:40 <dhellmann> what if we just propose a release, and not a model change? then they only have to choose between (1) and (3)
19:43:45 <ttx> that would work too. I just wanted to put the cycle model change on the table
19:44:11 <ttx> because I still think it's the best way to do "one release per cycle"
19:44:40 <ttx> If the PTL chooses (1) and proposes a release, we abandon our patch
19:44:49 <dhellmann> ok
19:45:12 <tonyb> ttx: That works for me.
19:45:37 <smcginnis> ttx: Would it be a good next step for you to respond on that thread summarizing this and get feedback before we go too much further in making any changes on our own?
19:45:38 <fungi> i guess the contention is between not knowing that they want more than 1 release for a particular cycle vs not being allowed to have more than 1 release for a given cycle?
19:45:51 <smcginnis> I just think it would be good for buy-in and spreading awareness.
19:46:10 <ttx> smcginnis: I could do that tomorrow, but feel free to beat me to it
19:46:34 <ttx> I fear the thread will explode ebfore I can post
19:46:54 <ttx> and my head is ready to explode, been a long day, so I;d rather not do anything tonight
19:47:23 * dhellmann promises not to post any more inflammatory messages to that thread
19:47:44 <tonyb> dhellmann: I didn't think it was inflammatory
19:47:51 <ttx> dhellmann: I started a post like yours but put it back in the draft box
19:47:57 <diablo_rojo> dhellmann, I didn't think it was inflammatory either
19:48:26 <dhellmann> maybe I managed to edit it out, then
19:49:12 <ttx> tonyb: I think we can move on to next topic
19:50:53 <tonyb> #topic Stuck reviews
19:50:56 <ttx> I noticed a few patches that seem to have trouble getting W+1ed
19:51:14 <ttx> https://review.opendev.org/#/c/670808/ (the stable-branch-mode:none one, maybe it's time to W+1)
19:51:30 <ttx> feel free to do that now :)
19:51:40 <ttx> https://review.opendev.org/#/c/670641/ (Update Python testing runtimes - not clear if that is something we want)
19:51:56 <ttx> I'm a bit unclear on that one
19:52:10 <ttx> I think we want it
19:52:39 <smcginnis> I'm for it.
19:52:40 <ttx> ?
19:52:46 <ttx> ok
19:52:48 <dhellmann> which version of python do our jobs use?
19:53:03 <fungi> looks like 3.6 and 3.7 right now
19:53:12 <tonyb> those ^^
19:53:15 <fungi> so in theory this change is a no-op, i think
19:53:22 <smcginnis> For our purposes, we could probably also just do py3 and not be as specific.
19:53:38 <smcginnis> But if all other OpenStack projects are requiring the use of py37, we might as well follow along.
19:53:53 <tonyb> I'm okay with it.  I didn't mean to slow it down that much
19:54:01 <fungi> yeah, it's not a repository which is released as part of the cycle (there's a bit of irony) so the supported runtimes pti is a bit less applicable
19:54:05 <ttx> I'll let someone with enough brain juice to understand it push the W+1 button
19:54:06 <fungi> but fine to follow
19:54:16 <ttx> https://review.opendev.org/#/c/672378/ (new_release reformat blocking Oslo releases)
19:54:26 <ttx> does anyone know why that happened?
19:54:35 <smcginnis> evrardjp fixed new-release.
19:54:51 <fungi> note that the python runtimes change is also self-testing so you can just see what jobs it ran
19:54:54 <smcginnis> Not sure why bnemec-pto hasn't updated that, but now that I see his nick I guess I know.
19:54:54 <ttx> so this needs to be reposted ?
19:55:06 <ttx> maybe the answer is in his current name
19:55:27 <ttx> ok, can someone leave a comment on that one?
19:55:33 <ttx> https://review.opendev.org/#/c/672307/ (should cycle-automatic allow intermediary releases ?)
19:55:47 <ttx> So we discussed that earlier
19:55:59 <ttx> I feel like cycle-automatic should not
19:56:32 <ttx> otherwise we make the autorelease not a exceptional corner case but more of a normal thing
19:57:00 <ttx> cycle-automatic was designed for things that technically need a release at the end of the cycle but where "the release" does not mean much
19:57:10 <ttx> and therefore was constantly overlooked
19:57:13 <fungi> marking time, in essence
19:57:27 <fungi> "this was the state of the repository at the time openstack released foo"
19:57:32 <ttx> I'd prefer if it stayed that way
19:57:50 <smcginnis> I could see teams liking the idea of releasing whenever they found a need, but knowing there will be a final one done for them. But per previous discussion, I'd rather avoid that extra work falling on this team.
19:58:21 <ttx> my understanding is that tempest does not really use the released version of the plugin ?
19:58:28 <ttx> but gets it from master?
19:58:46 <ttx> and since it is the only user of the plugin...
19:58:51 <tonyb> ttx: vendors package the releases (IIUC)
19:59:06 <fungi> the primary use case we discussed was refstack users
19:59:10 <ttx> tonyb: yes but not during the cycle right
19:59:18 <smcginnis> Apparently some do.
19:59:27 <tonyb> ttx: RDO does
19:59:31 <fungi> testing old openstack version $x, i use tempest $y and "corresponding" plugin versions
19:59:40 <smcginnis> Or at least that has been the response indicated when I've asked others when they've done interim releases of tempest plugins.
19:59:45 <ttx> ok
19:59:57 <ttx> so we can be OK with intermediary releases
20:00:06 <tonyb> ttx: basically if theere is a release of anything in OpenStack RDO will grab it ASAP
20:00:11 <ttx> as long as cycle-automatic is limited to corner cases
20:00:24 <ttx> (like tempest plugins)
20:00:26 <fungi> it's more being able to publish/track which versions of the plugins someone should use when using a particular version of tempest
20:00:30 <ttx> I don't really care
20:00:48 <ttx> it's a bit of a slippery slope but meh
20:00:57 <tonyb> fungi: That's a nice use too
20:01:04 <ttx> everyone ok with this?
20:01:19 <tonyb> ttx: Yup
20:01:30 <ttx> smcginnis: can you comment to that effect on that review?
20:01:40 <ttx> ISTR you were involved in it
20:01:41 <smcginnis> Yep, will do.
20:01:49 <smcginnis> I just posed the question.
20:01:56 <ttx> https://review.opendev.org/#/c/669746/ (the big YAML update... can we just merge it before it's outdated again)
20:02:06 <ttx> can we get this one in now?
20:02:38 <ttx> that was all I had
20:02:50 <ttx> and we are past time
20:03:00 <openstackgerrit> Merged openstack/releases master: Add stable-branch-mode:none option  https://review.opendev.org/670808
20:03:04 <tonyb> Just the PTG thing
20:03:06 <smcginnis> It's a small change but unfortunately touches a lot of files.
20:03:12 <ttx> Is PTG/FOrum planning urgent?
20:03:14 <tonyb> are we going? do we need space? howmuch?
20:03:22 <ttx> I'm going
20:03:30 <ttx> we can meet in a corner
20:03:34 <diablo_rojo> I'll be there.
20:03:37 <smcginnis> No official confirmation, but I believe I'm going.
20:03:43 <ttx> Half a day?
20:03:45 <tonyb> smcginnis: do you have a tool to check for late additions of 'true' ?
20:04:03 <tonyb> That sounds godo to me
20:04:08 <tonyb> I shall make it sow
20:04:10 <fungi> i'll be there and can join in discussions if i'm not too overbooked
20:04:11 <smcginnis> tonyb: The gate rebase on master should catch any, but I just rebased that this morning so I think we should still be good.
20:04:13 <tonyb> *so even
20:04:16 <dhellmann> I won't be there this time
20:04:24 <tonyb> dhellmann: :(
20:04:30 <dhellmann> yeah, :-(
20:04:46 <tonyb> smcginnis: I was thinking of like in a couple of weeks
20:04:51 <fungi> well, at least i'm as likely to be there as i can be, pending visa approval and hurricane season
20:04:56 <diablo_rojo> dhellmann, there is always TSP..
20:05:12 <ttx> alright then, I need to run
20:05:48 <tonyb> #endmeeting