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