14:01:55 <dhellmann> #startmeeting releaseteam
14:01:56 <openstack> Meeting started Fri Feb 26 14:01:55 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:59 <openstack> The meeting name has been set to 'releaseteam'
14:02:20 <dhellmann> our agenda is under R-6 in https://etherpad.openstack.org/p/mitaka-relmgt-plan
14:02:26 <dhellmann> courtesy ping: dims, ttx
14:05:59 <ttx> o/
14:06:06 <kzaitsev_mb> o/
14:06:20 <dhellmann> #topic release testing summary
14:06:24 <kzaitsev_mb> (I maybe have a couple of questions for the open discusssion part if any)
14:06:30 <dhellmann> kzaitsev_mb : sure thing
14:06:49 <dhellmann> kzaitsev_mb : if not here, in #openstack-release right after the meeting
14:07:26 <dhellmann> ttx: aside from the bug in the pypi link flag, and the tarball link, did we find any other issues we need to address?
14:07:59 <ttx> Looking at the email template it would have sent at release
14:08:48 <dhellmann> it didn't include any reno output
14:08:54 <ttx> "This release is part of the meiji stable release series." -> This release is the initial (final?) meiji release for X" ?
14:09:03 <dhellmann> hmm
14:09:08 <dhellmann> yeah, I'll have to see about that
14:09:23 <dhellmann> we might just want to remove "stable", I'm not sure it's easy to detect the 'first" release in a series
14:09:31 <ttx> Something that says that it's *the* meiji release basically
14:09:43 <ttx> rather than part of a stable series that doesn't really exist yet
14:09:43 <dhellmann> at least not at the point where the announcement is generated
14:10:11 <ttx> our usual wording calls it the "final" release
14:10:17 <ttx> but that may be confusing
14:10:41 <ttx> Also Subject: [release][stable] openstack-release-test 0.0.1 release (meiji) should definitely not say [stable]
14:11:04 <ttx> for the same reasons
14:11:42 <ttx> apart from that and the other points you raised I think I have no other issue to report
14:11:48 <dhellmann> the stable flag is detected by looking at the name of the branch right now
14:12:08 <ttx> yep, we might want some kind of bypass flag in the tag metadata
14:12:33 <dhellmann> yeah, I'll look at that, too
14:12:37 <ttx> dhellmann: http://releases.openstack.org/meiji/index.html
14:12:51 <ttx> didn't we say we would collapse the a1 -> rc2 by release time ?
14:12:52 <dhellmann> we would have had reno output in the email, too, if the default for "collapse" was true
14:13:13 <dhellmann> I thought we were only going to do that in the release notes?
14:13:25 <dhellmann> you want to do it on the releases page, too?
14:13:39 <ttx> dhellmann: on that page you want "earliest version" to be 0.0.1, not the a1
14:13:55 <dhellmann> ah, true
14:14:04 <dhellmann> ok, I'll put that on my list, too
14:14:05 <ttx> since those are considered temporary production artifacts
14:14:31 <dhellmann> so is it just the earliest version that should change, or should we hide the pre-releases in the detail list, too?
14:14:49 <ttx> I think we should hide them from the detail list too
14:15:00 <ttx> They can survive in the yaml for historical purposes
14:15:19 <ttx> alternatively we could clean up the yaml
14:15:30 <ttx> since we are the ones promoting the latest RC to release
14:15:37 <dhellmann> cleaning up the yaml would definitely be the simplest answer
14:15:43 <dhellmann> although it's more labor
14:15:49 <ttx> after all the hisotory lives in the tags
14:15:52 <dhellmann> let me see what I can do to automate it
14:16:03 <ttx> well, we could have a script that proposes the promotion
14:16:30 <ttx> some kind of promote_latest_RC_to_final nova meiji
14:16:35 <dhellmann> yeah, once I figure out the logic for ignoring the pre-releases we might as well do it in the rendering
14:16:47 <dhellmann> I have it in reno, I just need to adapt it for this case
14:17:13 <ttx> ok, that is all I could find
14:17:15 <dhellmann> so if that's it, we can move on
14:17:34 <dhellmann> #topic process releases requests backlog
14:17:48 <dhellmann> I can do this after the meeting, since we have some other things to discuss
14:18:01 <ttx> Sure, let's process it after meeting
14:18:11 <dhellmann> #topic summit space needs
14:18:27 <dhellmann> last time we had 1 fishbowl, 1 work space, and shared our Friday meetup space with QA
14:18:49 <dhellmann> that feels about right for this time, too. I think we got more done on Friday than in the work space meeting, didn't we?
14:19:04 <dhellmann> although I guess we used the work space meeting to set up the plan to start the discussion for friday
14:19:09 <ttx> so on the fRiday we can work on the newton-relmgt-plan
14:19:47 <ttx> I think we should have a fishbowl to discuss future changes in release management, in particular the take-back-tagging approach
14:19:57 <dhellmann> I plan to ask fungi for a slot to discuss the rest of the work needed to complete the automation
14:20:09 <dhellmann> yeah, that's a good use for a fishbowl
14:20:15 <ttx> we can discuss infra last steps at that same fishbowl
14:20:28 <ttx> so 1 Fishbowl + 1 meetup ?
14:20:52 <ttx> or you want another fishbowl for reno ?
14:21:11 <dhellmann> I was thinking a working session for reno, but we could also address that on friday
14:21:36 <dhellmann> I have some ideas about using sphinx's built in support for i18n, I just haven't gotten to a point where I've tried them to see if they'll work
14:22:27 <ttx> I just wondered if you wanted external feedback on reno, in which case a fishbowl would look better
14:22:40 <dhellmann> I see
14:22:54 <ttx> I tried to group things on the agenda
14:22:55 <dhellmann> yeah, a fishbowl discussion of how it is working would be good, but that's not what I had in mind for the i18n discussion
14:23:06 <ttx> the first 4 topics can fit in that automation fishbowl
14:23:28 <ttx> but reno is slightly off-topic there and maybe too much for a single session
14:24:23 <ttx> 2 fishbowls sound a bit too much
14:24:37 <dhellmann> yeah, how about like I have it now?
14:24:41 <ttx> I think that can fit
14:24:52 <ttx> so 1 0 1
14:25:31 <dhellmann> yeah, I think so, unless there's something else we need a working session for
14:25:55 <ttx> stable team will have their own
14:26:10 <dhellmann> true
14:26:20 <ttx> lgtm
14:26:50 <dhellmann> ok, I just moved the brainstorming topic to the meetup day
14:27:01 <dhellmann> moving on then
14:27:02 <dhellmann> #topic library stable branches
14:27:15 <dhellmann> we have on the schedule to create stable branches for libraries next week
14:27:36 <dhellmann> we should have final releases done today, so next week makes sense I think, but I thought it was worth doing a gut check
14:28:01 <dhellmann> we could wait, to avoid needing to backport changes, but I don't think we have that many usually
14:28:10 <ttx> I think it makes sense. In theory projects could declare their RC1s Friday so we could have stable branches there too
14:28:22 <dhellmann> yep
14:28:37 <dhellmann> ok, so we'll stick with that plan
14:28:40 <ttx> The trick is... master changes will be tested against master libs ?
14:28:52 <dhellmann> yes, that's another reason for waiting
14:29:00 <ttx> bah, we freeze master release, no ?
14:29:09 <dhellmann> that's right
14:29:35 <dhellmann> bug fixes in the libs will be tested against master of the projects since the bug fix needs to go into lib master before lib stable
14:29:38 <ttx> so since we only use released libs... that should be the same
14:29:49 <dhellmann> then master apps are tested against released libs
14:29:53 <ttx> (from a project perspective
14:29:55 <dhellmann> so I think from a testing perspective we're covered
14:29:55 <ttx> )
14:30:33 <dhellmann> so, sticking with the current plan and branching next week
14:30:39 <dhellmann> I'll work with dims on that
14:30:53 <ttx> yep, maybe do a first batch and see how many yell
14:31:36 <dhellmann> yeah, we only have a few non-client libs outside of oslo so it shouldn't be hard to track down owners
14:31:46 <dhellmann> and we'll do the clients after they freeze next week
14:32:21 <dhellmann> #topic priority reviews
14:32:30 <dhellmann> we have a handful of reviews for tool changes
14:32:40 <dhellmann> #link fix default handling for pypi link  https://review.openstack.org/285311
14:32:40 <dhellmann> #link collapse pre-release notes into regular releases by default https://review.openstack.org/#/c/278761/
14:32:40 <dhellmann> #link support tarball names that don't match the repo name https://review.openstack.org/#/c/284870/
14:32:47 <ttx> https://review.openstack.org/#/c/284870/ fails tests
14:32:53 <ttx> I +2ed the other two
14:33:16 <dhellmann> I'll look, but I assumed the test failure was because it depends on the release that you just tagged
14:33:21 <dhellmann> if it's something else I'll fix it up
14:33:51 <ttx> yes, rechecking
14:34:08 <dhellmann> jinkx
14:34:31 <dhellmann> I think that's it for the formal agenda
14:34:34 <dhellmann> #topic open discussion
14:34:45 <dhellmann> kzaitsev_mb : you had a question?
14:35:08 <kzaitsev_mb> yep, 1st question I had — is there a source of truth for meta tags?
14:35:16 <dhellmann> meta tags?
14:36:38 <dhellmann> kzaitsev_mb : I'm not sure what you mean by "meta tags"
14:37:10 <ttx> dhellmann: +2ed that last review
14:37:20 <kzaitsev_mb> dhellmann: sorre, had a competitive meeting
14:37:38 <kzaitsev_mb> I mean meta tags in tag messages seem to be a little magical
14:37:44 <dhellmann> kzaitsev_mb : do you want to drop by #openstack-release after your meeting?
14:37:54 <kzaitsev_mb> is there maybe a wiki, that describes those?
14:38:28 <dhellmann> kzaitsev_mb : oh, the data in the comment for tags? that info is built by the script we use to generate the tag. you're not meant to have to add it by hand.
14:39:25 <kzaitsev_mb> dhellmann: hm. that probably means, that I'm probably doing it wrong. I mean releasing and tagging things in murano
14:40:22 <kzaitsev_mb> ok, I'll drop by at #openstack-release and ask you guys how should I release my repos
14:41:03 <dhellmann> kzaitsev_mb : sounds good
14:41:09 <dhellmann> ttx, did you have anything else?
14:41:14 <ttx> dhellmann: listed the release testing gaps on the etherpad
14:41:26 <ttx> in case you want to line up actions against that
14:41:42 <dhellmann> ttx: great, thanks, I had notes on paper here but that's much better
14:41:53 <ttx> make sure i didn't miss anything
14:42:03 <dhellmann> I'll cross-check
14:42:18 <ttx> that is all
14:42:31 <dhellmann> cool, thanks
14:42:32 <dhellmann> #endmeeting