15:00:04 #startmeeting releaseteam 15:00:05 Meeting started Fri Oct 12 15:00:04 2018 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:08 The meeting name has been set to 'releaseteam' 15:00:22 Ping dhellmann, evrardjp, armstrong 15:00:25 hello 15:00:29 Morning! 15:00:32 o/ 15:00:38 o/ 15:00:57 Don't want to leave you out annabelleB if you are still here. :[ 15:00:58 o/ 15:01:06 Hey abhishekk! 15:01:11 https://etherpad.openstack.org/p/stein-relmgt-tracking 15:01:15 hey 15:01:16 o/ 15:01:17 R-26 week 15:01:32 annabelleB: Yay, you haven't abandoned us yet. :) 15:01:41 hehe, here for another week! 15:01:56 annabelleB: We'll take you as long as we can get you! 15:01:56 ooo, short-timers ;-) 15:02:09 #topic Handling version increases at the start of each cycle 15:02:19 dhellmann: All yours. 15:02:37 I wrote up the basics of this in the meeting agenda 15:02:48 o/ 15:02:56 the shift away from having milestone tags is going to make upgrade testing downstream more complicated 15:03:18 there are a few ways to fix that upstream, and I've proposed a patch to implement 1 of those ways by injecting pbr instructions to bump the versions on master 15:03:22 after we create branches 15:03:46 but to be clear, it's still possible to create milestone for those who want, right? 15:03:53 evrardjp : oh, yes, definitely 15:03:54 So I don't know pbr well enough, but just having something in the commit message will trigger something with pbr that will handle this? 15:03:56 or whatever we name it 15:03:59 although I don't expect anyone to actually do it 15:04:01 so the situation doesn't change? 15:04:11 smcginnis : yeah, it's a not-well-documented feature 15:04:16 let me see if it's even mentioned... 15:04:27 evrardjp: I would think most will not do a milestone release, but they certainly can if they want to. 15:04:44 it's mentioned here: https://docs.openstack.org/pbr/latest/user/features.html#version 15:05:05 smcginnis: my point was that for those who were already late in the past and triggered those policy changes HAD to be dealt with in the past too... 15:05:18 heh, the docs say "Sem-Ver" but the code looked case-insensitive so I used sem-ver I think 15:05:52 the policy change isn't about adding a new requirement, it's about relaxing one 15:06:12 so it's not really something we need to make retroactive, if that's what you mean 15:07:01 Looks like adding that sev-ver bit will be pretty easy to do with your patch for opening up master on branching then. 15:07:05 not really but let's ignore my comment until I rephrase them correctly 15:07:42 evrardjp : I'd be happy to try to answer your question. Sorry if I've misunderstood. :-/ 15:08:17 smcginnis : yeah, the only tricky bit will be dealing with stein, since we're well into the cycle 15:08:20 I am trying to take a few steps back, it's just that :) 15:08:32 we could just generate empty patches with the semver bump, I guess 15:08:38 dhellmann: Blast out a trivial update to all repos? 15:08:43 Yeah 15:08:49 that sounds an easy fix 15:08:51 the patch itself can be empty, we just need the commit message 15:08:57 One time thing, so not too bad. 15:08:58 what about those who aren't using pbr? 15:09:10 who is responsible for making changes on release model, for example, to drop the milestones ... etc? 15:09:11 evrardjp : we shouldn't have any official projects in python not using pbr 15:09:40 armstrong : the release team defines the models, and each project team signs up for the ones they want to use for their deliverables 15:09:45 armstrong: In this case, the release team would handle switching all stein deliverables over from cycle-with-milestone to cycle-with-rc. 15:09:50 smcginnis already has a patch up to modify the existing deliverable files for stein 15:10:08 * smcginnis totally forgot he did that :) 15:10:13 #link https://review.openstack.org/#/c/606860/ 15:10:30 sed for the win 15:10:47 so true 15:10:53 :) 15:11:19 So... any concerns with this approach? It seems good to me. 15:11:41 And we haven't had any other feedback on that other than the internal RH team. 15:11:55 we should probably publicize it on openstack-dev 15:11:59 as long as it has a proper topic in gerrit I am good :) 15:12:01 I can send an email today 15:12:07 although I won't be around to answer questions 15:12:07 and this ^ 15:12:25 dhellmann: Publicize that we are going to have these patches? Or that we are making the -rc switch? Or both? 15:12:40 the patches 15:12:51 Yeah. That has potential for a lot of confusion. 15:12:52 I think it's worth explaining the patches and remind the context 15:12:54 I think the thread about the rc change already mentions the downstream version issue 15:12:57 I can reply to that 15:13:20 that works too 15:13:27 Did you want to take on generating those patches or should I? Or other volunteers. 15:13:44 I'm going to be out for a couple of weeks or I would offer to do it 15:13:51 it seems very scriptable 15:14:02 dhellmann: Got get your patch count up for the cycle. It's kind of low. :P 15:14:10 haha 15:14:12 I should give someone else a chance ;-) 15:14:19 OK, I can take that action. 15:14:20 lol 15:14:27 I think the one sending the email should do it 15:14:29 it's clearer 15:14:37 dhellmann: If you want to announce it on the ML, I can work on generating the patches. 15:14:54 ok, I'll mention that you're going to be submitting the patches on behalf of the release team 15:15:04 that should avoid any confusion, as evrardjp points out 15:15:19 Either way. If we think it would cause any confusion I can also post the info the ML. 15:15:30 do we want to wait and get ttx's input on this? 15:15:33 But saying to watch for patches from me should be OK. 15:15:35 yup that should be good. I mean not everyone has followed what's going on, and a few would be surprised, so the ML mail will be important IMO 15:16:01 It will be important to have enough info in the commit message to explain this too. 15:16:22 having the ML thread out there ahead of the patches means the commit messages can link to it, too 15:16:23 but yeah 15:16:23 Not sure if we want to wait for ttx since he's globetrotting right now. 15:16:30 dhellmann: True 15:16:33 "git commit --allow-empty" is the thing you want 15:16:44 Thanks, was going to confirm that. ;) 15:17:28 we should probably include all of the deliverables that haven't been released for stein but that were released in rocky 15:17:28 OK, anything more on cycle-with-rc? 15:18:12 Yeah, anything released in rocky would be a good basis. Not sure if we've had anything in stein that was not also released in rocky. 15:18:16 not from me 15:18:32 I think we had 1-2 things added as new, but I can't think of the names 15:18:41 I'll double check. 15:18:42 it's not the end of the world if those get the patches anyway 15:18:44 yeah 15:18:59 True, if they are new in stein, then it doesn't really matter in this case. 15:19:09 Nothing to upgrade from. 15:19:11 right 15:19:30 #topic cycle-with-intermediary lib changes 15:19:47 I posted to the ML yesterday about these changes. 15:19:56 So far one positive feedback from searchlight for it. 15:20:26 it would be good to have some more feedback, since it's going to hit mostly client libraries 15:20:33 #link http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html 15:20:51 Yeah, I think this one will have a bigger impact than the -rc change. 15:21:04 So we should probably wait a bit before taking any action. 15:21:13 Though stein-1 is coming up soon. 15:21:46 yeah, it might be worth forwarding that email to the ptls or liaisons directly 15:22:05 this is a bigger than usual sort of change, since it means releases they may not be expecting 15:23:06 I'll look at doing that. Last time I tried contacting all PTLs I think I almost had my account shut down. 15:24:31 Did you want to remove your -2 from that sem-ver patch? 15:24:37 I suppose there's no rush on that one though. 15:24:58 Just thinking with you being out the next two weeks. 15:24:59 I'll fix the case issue and submit it again and not WIP it 15:25:05 OK 15:25:12 Anything more to discuss on lib changes? 15:25:27 we should test that after it lands before submitting the patches to the projects to make sure I got the semver thing right :-) 15:25:45 we can make a branch in the release-test repo 15:26:05 OK, good. That should be a quick test. 15:27:02 #topic Open discussion 15:27:08 Anything else for today? 15:27:47 nothing from mee 15:27:56 * elbragstad doesn't have anything 15:28:08 nothing 15:28:21 OK, thanks everyone. 15:28:29 thanks 15:28:32 #endmeeting