15:02:11 #startmeeting releaseteam 15:02:13 Meeting started Fri Mar 9 15:02:11 2018 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:16 The meeting name has been set to 'releaseteam' 15:02:24 Ping list: dhellmann, dims, fungi, tonyb, lbragstad, smcginnis, armstrong 15:02:47 Agenda https://etherpad.openstack.org/p/rocky-relmgt-tracking R-25 15:03:03 A few topics I added 15:03:31 I can't remember if we're ready to take the default series patch now or if that should wait for the finals for the trailing projects 15:03:34 There is a default series patch https://review.openstack.org/#/c/548564/ 15:03:43 right that was my question 15:04:02 At this point I'd just wait until next week and approve it once we are past cycle-trailing deadline 15:04:15 yeah, that seems safest 15:04:16 but there might be good reasons not to 15:04:40 let me look at where that value is used again... 15:05:20 there are some validation rules that only apply to the "current" release 15:05:46 so it's probably best to wait to approve it 15:05:51 we should probably change that set of rules to be a bit more flexible 15:06:04 and say they don't apply to "old" releases instead of that they only apply to the "current" release 15:06:32 ack 15:06:39 so after we approve https://review.openstack.org/550678 we can update the default safely 15:06:55 #agreed let's wait until past cycle-trailing deadline to approve https://review.openstack.org/#/c/548564/ 15:06:59 #topic Packaging as part of "the release" / cycle-trailing 15:07:30 I'm not sure what this topic is about 15:07:30 So there was a bit of a mismatch with release comms around new projects 15:07:50 They were assumed as part of the release but were not 15:07:59 For some it's pretty clear cut 15:08:32 For others it's a bit more confusing 15:08:43 They all failed the milestone-2 inclusion deadline 15:09:01 ah, yes, we talked about documenting the policy for that more clearly 15:09:13 But that made me wonder... 15:09:27 Like for LOCI or openstack-helm, they will do a queens release 15:09:47 since that is downstream, that will happen cycle-trailing, probably later than the deadline 15:10:10 we do separate those trailing projects out on the release pages: https://releases.openstack.org/queens/index.html#projects-trailing-the-release-cycle 15:10:53 I guess my question is.. is the milestone-2 deadline of any value for cycle-trailing stuff 15:10:59 *And* 15:11:15 shoudl we open up the cycle-trailing to more than two weeks 15:11:35 hmm 15:11:45 boils down to the "what is the release" question. We use teh term for a series and a coordinated release. 15:11:59 it has some impact on signing key rotation as well 15:12:03 I'm comfortable being pretty relaxed with the deployment tools 15:12:20 I think people consider those more "compatible with" or "for" a series than "part of" the series. 15:12:24 Would not be crazy to consider packaging to not be part of the release anyway 15:12:30 right 15:12:37 (release in the coordinated release sense) 15:12:45 we'd have to decide whether we want to continue to delay swapping out the signing key until all cycle-trailing releases are complete, or just live with the fact that some cycle-trailing queens releases will get signed by the rocky cycle key 15:12:55 fungi : interesting point. I thought those were mostly time based, though? I mean, we will use the rocky key to sign queens patch releases, right? 15:13:03 For example release communications mention openstack-helm and LOCI being new options, while tehy are technically not out yet 15:13:23 dhellmann: correct, so it's not much of a leap to just continue with the normal schedule 15:13:32 from a key rotation perspective 15:13:42 ttx: oh, we don't even have betas of those? 15:14:02 we don't have tags yet, so hard to tell :) 15:14:13 fungi : right 15:14:29 I feel like at this stage it's more master benig WIP for queens 15:14:34 being 15:14:35 yeah 15:14:59 IIRC they said that they were still catching up and won't be ready to be aligned with our deadlines before R 15:15:21 which is far, but I wonder what is the value of saying it's not there 15:15:23 fair 15:15:43 it's unfortunate that we've announced that they are options before they really are, but I guess they can be used from source so maybe the tag is less important there 15:15:49 vs. just saying we have a release and a bunch of packaging for it that comes out later 15:16:14 right, I think it's ok to say that packaging and deployment tools are "for" a series and may come out after the actual software 15:16:15 dhellmann: they probably are options already. Just not tagged. 15:16:20 right 15:16:38 so you mentioned extending the 2 week period, too? 15:16:57 dhellmann: I wonder what is the value of enforcing a short delay 15:17:33 Like if openstack-helm feels ready to bless their release 3 weeks after, it's probably better to include them rather than pretend they don't exist at all 15:17:46 yeah. I guess initially we wanted to have the deployment projects working closely with the other projects all along, but 2 weeks has always felt a little tight. 15:18:00 do we want to drop the deadline entirely? 15:18:04 Well initially we also wanted to see everything as being a single "release" 15:18:09 true 15:18:36 now that we have more clearly delineated what is the thing and what is packaging for the thing... opens up options 15:18:51 the only concern I have about changing deadlines is the effect of branching, or not, at the right time 15:18:57 We won't solve it now, just wanted to raise it while fresh 15:19:12 most of those projects don't say they follow the stable policy, so they could branch early and backport fixes, but that feels like making extra work for them 15:20:04 it may take a bit more thought to figure out whether there is a big impact on them, or if they would have to take any special precaution after a series is branched 15:20:12 Like LOCI will likely want to tag their 1.0.0 anytime now 15:20:33 Not sure there is much value in not including them 15:20:53 There is value in not adding main components too late 15:20:57 I'm fine with extending the deadline for an initial release 15:21:01 sice that affects said packagers 15:21:09 BUT adding packaging systems... 15:21:14 maybe we say they have to release for Q before the end of R? 15:21:34 dhellmann: that sounds reasonable 15:21:50 I don't think we want it completely open ended, and that's a pretty generous deadline. 15:22:07 Basically our pre-milestone-2 inclusion rule is there to protect packagers 15:22:09 maybe R-3, so the gate doesnt get extra clogged at rc-tine 15:22:13 Not to ignore them 15:22:22 * EmilienM hides 15:22:34 one thing we've done on the infra side is try to accomodate main release and trailing releases with things like gerrit upgrades and project renames and so on 15:22:51 rosmaita : sure, that makes sense 15:22:54 if we update that maybe we need to have an infra update window clearly defiend so that people are aware of when those might happen 15:23:08 clarkb : I think we'd all benefit from that, yes. 15:23:18 (meaning milestone-3 not release-3) 15:23:45 right 15:24:35 ttx: do you want to propose the change in the deadlines for queens and rocky? I guess we need to update the description of the release model, too. 15:25:44 dhellmann: I can drive that yes. Not sure we want that deadline on the schedule page since that would make the table VERY long 15:26:35 dhellmann: apparently LOCI is discussing their release on #openstack-loci right now 15:29:19 ttx: I think we could have the deadline without the intervening weeks 15:29:41 yeah that's what I was thinking 15:30:57 And maybe change the wording on release pages, rather than say trailing, say packaging for 15:31:21 change the name of the model? or just the headings on the page? 15:31:25 since that's a 1:1 15:31:33 Let's say heading on page for now 15:31:38 sure, that's an easy one 15:32:16 Now that we said that only packaging stuff can use cycle-trailing... 15:32:19 the model isn't hard, but I think there's a place where we have a check for "cycle" in the name so if we change it to something like "packaging-tool" we would need to find that spot 15:32:29 yeah 15:32:44 we could make it cycle-packaging but meh 15:34:43 yeah, at this point cycle-packaging might just be simpler :_ 15:35:11 OK, the last topic I had was around task tracking, but I'd rather wait for our fearless leader return 15:35:26 yeah, that's one for us to discuss together 15:35:33 did the patch to enable storyboard for the releases repo land? 15:36:11 not sure 15:36:34 no: https://review.openstack.org/#/c/548928/ 15:36:48 maybe fungi can put that on his review queue ^^ 15:37:16 or clarkb 15:37:21 sure 15:37:37 no particular rush, but it should be an easy one 15:37:43 oh, i was the one who proposed it 15:37:48 oh, duh 15:37:52 but clarkb or someone could approve it ;) 15:38:09 once it merges i can import the reno bugs too 15:38:18 that would be good, thank you 15:38:18 and then we can close down the reno tracker on lp 15:38:27 ++ 15:38:32 I can do the LP side I think 15:39:04 do we have docs for that? or is it just a matter of closing the bugs and turning off the bug tracker in LP? 15:40:59 basically that, but i think there are some recommendations/checklist recorded for it 15:41:05 diablo_rojo: ^ you probably remember? 15:41:28 I can take a look at it 15:41:30 like, add a url to the new bug tracking location in the lp project description 15:41:49 just general suggestions to help users find the new location more easily 15:42:24 sure, that makes sense 15:43:02 hmm, does someone have to register with the foundation in order to file a story on storyboard? 15:43:20 should I hold off on approving it for the migratio nto be sorted out? 15:43:36 #link https://docs.openstack.org/infra/storyboard/migration.html#recently-migrated 15:43:50 dhellmann: no it is using ubuntuone right now 15:43:52 clarkb : nah, I'll work with fungi on coordinating the reno bugs 15:43:54 so same accounts as lp 15:44:01 ok, good 15:44:33 I wonder if we can also make that work with github or something, just for storyboard, so anyone can file bugs easily 15:44:44 at least after we move it over to the foundation auth provider 15:44:46 we haven't switched the sb auth away from lp yet, and now there's some further considerations as we start hosting other communities besides openstack 15:44:56 yeah 15:45:02 so, yes, taking lots of that into account 15:45:10 I'm also thinking of users of some of these tools outside of the main community entirely 15:45:16 right 15:45:26 ok, it sounds like you've thought about all of this already 15:45:37 fungi: and no reason to hold off approving on your side? 15:46:47 clarkb: no reason--go for it 15:49:04 i have a question before we adjourn 15:49:13 rosmaita : sure, what's up? 15:49:17 https://docs.openstack.org/glance/latest/contributor/release-cpl.html#final-releases 15:49:22 first bullet point 15:49:26 is that still a thing? 15:50:36 you could do that, but I don't think you have to 15:50:49 not all projects bump their major version number each cycle 15:52:03 is the problem that until milestione 1, development will still be happening in 16.x not 17.x (for glance) 15:52:57 yes, that will affect anyone trying to package from the queens branch and master and test upgrades using those packages 15:53:46 ok, so it may be a useful thing to do? i dont' know that we have ever actually done it 15:53:57 the folks at red hat raised that, but I think we figured out a way to fix it in their pipeline without doing things upstream 15:54:21 ok, i may just remove it from the contributor docs so i won;t keep asking about it every cycle 15:54:30 I wouldn't worry too much about it unless someone actually has a problem; I don't think any of the other projects do it. 15:54:34 :-) 15:54:44 works for me, thanks! 15:56:26 alright 15:56:31 Time to close 15:56:35 Anything else ? 15:56:41 i've generated and uploaded the rocky cycle signing key to the keyserver network (it's only signed by the queens key so far, i'll be attesting to it and uploading my own signature shortly, then socializing it with the rest of the infra-root team to do the same) 15:56:45 #link https://sks-keyservers.net/pks/lookup?op=vindex&search=0xc31292066be772022438222c184fd3e1edf21a78&fingerprint=on Rocky Cycle Signing Key 15:57:02 it may not be on all the keyservers yet so might take a refresh or two at the moment to see it 15:57:13 just uploaded around 45 minutes ago 15:57:26 ack keep us posted when you signed it 15:57:37 will let you know in #openstack-release yes 15:57:43 alright 15:57:49 Time to close 15:57:52 Anything else ? 15:57:57 :) 15:58:01 nothing from me 15:58:07 #endmeeting