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