14:00:56 <dhellmann> #startmeeting releaseteam
14:00:56 <openstack> Meeting started Fri Aug  5 14:00:56 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:59 <openstack> The meeting name has been set to 'releaseteam'
14:01:07 <dhellmann> courtesy ping: ttx, dims, tonyb, stevemar, fungi
14:01:11 <ttx> o/
14:01:21 * fungi feels he has been done a courtesy
14:01:22 <dhellmann> #link https://etherpad.openstack.org/p/newton-relmgt-tracking
14:01:32 <dhellmann> this is R-9 on the tracking pad
14:01:37 * dims not fully here
14:01:44 * fungi is never _fully_ here
14:01:51 * stevemar also not fully here :)
14:02:34 * dhellmann prepares to run a partial meeting
14:02:38 <dhellmann> #topic automation progress
14:02:54 <dhellmann> debugging last week and earlier this week uncovered some more issues
14:03:13 <dhellmann> we're currently waiting for https://review.openstack.org/#/c/349023/ to merge before testing again
14:03:24 <fungi> the only outstanding topic:artifact-signing now have been approved (1349022, 1349023)
14:03:29 <fungi> just a few minutes ago
14:03:45 <dhellmann> yep, so either later today or monday I'll run another test round
14:03:47 <fungi> should be in place by the end of the meeting
14:04:05 <dhellmann> oh, right, you don't have to wait for the integrated gate :-)
14:04:12 <dhellmann> s/you/we/
14:04:36 <dhellmann> let's move on to the main topic for today
14:04:37 <fungi> and releases are now accompanied on tarballs.o.o by detached openpgp signatures (with the same key that will soon be signing git tags)
14:05:07 <fungi> we have a few infra-root keysigs on it too now but need a few more before i'm comfortable
14:05:13 <fungi> i'll keep pushing on that
14:05:17 <dhellmann> good! I think we deferred the task we had to add those links to the releases site, but if we finish some of the other priorities we can work on it
14:05:29 <fungi> and i have documentation still outstanding for the releases site, yeah
14:05:42 <fungi> also i should get https going for that site soon
14:05:43 <dhellmann> oh, I meant the links to the signatures, not the keys
14:05:59 <fungi> if we expect people to trust key fingerprints we list on it
14:06:10 <dhellmann> and you'll let us know when you're ready for the release team to sign the keys, too?
14:06:15 <dhellmann> yes, good point
14:06:16 <fungi> yep
14:06:18 <dhellmann> k
14:06:36 <dhellmann> I think that covers it, unless there's anything else?
14:06:55 <fungi> not from me anyway
14:07:00 <dhellmann> #topic Cycle status checkup
14:07:21 <dhellmann> I went through the planning document this morning and tried to catch all of the priority items that were still open
14:07:30 <dhellmann> I've copied them to the meeting agenda to make it easier to talk about them
14:08:04 <dhellmann> please quickly look through the list to make sure I didn't miss something you're working on and consider important, and then we'll go through them and check the status and reprioritize as needed
14:08:20 <dhellmann> please ack here when you're done with the quick review
14:09:02 * dims reviewing
14:09:36 <ttx> looks complete to me
14:09:41 <dims> done
14:09:45 <dhellmann> k
14:09:51 <dhellmann> documentation, then
14:10:12 <dhellmann> we talked about clarifying RC patches to avoid having to watch all of them ourselves
14:10:16 <dhellmann> where would we put that, the PTG?
14:11:20 <ttx> dhellmann: sounds good to me
14:11:33 <ttx> acronym collision detected
14:11:45 <dhellmann> ttx: you only just noticed that? I thought you did it on purpose.
14:11:59 <dhellmann> documenting it seems like it would also imply leaving it up to teams to manage
14:12:01 <ttx> heh
14:12:04 <mordred> we should work on the PTG at the PTG
14:12:32 <ttx> we could give a room to the PTG WG at the PTG for the PTG
14:12:42 * dhellmann has lost control
14:12:47 <dhellmann> ok, tools
14:12:49 <dims> LOL
14:13:10 <dhellmann> I agree with the comment in the etherpad that we don't need to build a new dashboard tool
14:13:23 <dhellmann> the google doc wasn't terrible last time, so we might use that again
14:13:24 <ttx> We /may/ still track this time, but using old ways
14:13:30 <dhellmann> right
14:13:38 <ttx> with an eye on not tracking in the future
14:13:56 <ttx> so dashboarding might not be the best use of our limited time right now
14:14:02 * dhellmann prepares some stern language for the RC period opening email
14:14:30 <dhellmann> how about the release announce script?
14:15:06 <dhellmann> I think that's a change to announce.sh to recognize when the previous release is an rc, and keep looking backwards until it finds something that is a better base
14:15:45 <dhellmann> does someone want to volunteer?
14:16:10 <ttx> I only have one work week available in next 3 weeks so I prefer to limit promises
14:16:27 <dhellmann> ok, we'll leave that open for now
14:16:40 <dhellmann> how about skipping release announcements for milestone server projects?
14:16:51 <dhellmann> I'm not sure I like this idea, but ttx you felt it was important?
14:17:32 <ttx> oh, right. The idea was to be able to send an "Newton released" email
14:17:53 <dhellmann> right. there's a separate item somewhere to do that automatically when we tag openstack/releases, but I think I deferred that
14:18:04 <ttx> if you have tons of emails sent earlier saying Nova 14.0.0 is released, it's a bit harder to "announce"
14:18:49 <dhellmann> yeah. I guess that final announcement didn't include the version numbers, did it?
14:19:04 <ttx> it did
14:19:16 <ttx> a list of all the components in "Newton" with version numbers
14:19:19 <dhellmann> it feels a little odd to not send announcement emails for the final releases, when we do send them for the rcs
14:19:24 <dims> We do need feedback for milestone server releases, right? need folks to kick tires
14:19:42 <dhellmann> dims : yes, this would be for projects using milestones but when they release their final
14:19:49 <ttx> do we annoucne RCs ?
14:19:50 <dhellmann> projects following cycle-with-milestones
14:20:00 <dims> ack dhellmann
14:20:06 <dhellmann> ttx: I thought so, but maybe not?
14:20:16 <dhellmann> were we doing those by hand?
14:20:22 <ttx> IIRC we manually mention them in -dev
14:20:28 <ttx> *nothing in announce
14:20:32 * ttx checks
14:20:39 <dhellmann> yeah, that seems right
14:21:02 <dhellmann> so if we are going to skip the automatic announcements of finals altogether, we don't need to fix the diffing issue
14:21:28 <ttx> ok, so re-reading mitaka there were two issues
14:21:43 <ttx> "announcements contain only
14:21:45 <ttx> partial release notes (usually only mentioning post-RC1 changes)"
14:21:53 <dhellmann> that's the diff issue
14:22:16 <ttx> + the recent flurry of announce emails. We are preparing
14:22:18 <ttx> for the final Mitaka release
14:22:22 <ttx> which may or may not be a bug
14:23:04 <ttx> For the "Mitaka released" email we just pointed to http://releases.openstack.org/mitaka/, no list of versions
14:23:05 <dhellmann> the simplest change would be to skip announcing final releases for projects that follow the milestone model
14:23:25 <dhellmann> I think we talked about release.sh adding metadata to disable announce.sh
14:23:41 <anteaya> but keeping the emotions, yes?
14:23:43 <dhellmann> ok, I thought I remembered just linking to the site
14:23:52 <ttx> so 1/ skipping all RCS and final, 2/ send final and fix release notes so they are complete
14:23:59 <dhellmann> anteaya : yeah, for when emails are sent
14:24:03 <anteaya> that is my favourite part of announce.sh
14:24:05 <anteaya> thank you
14:24:09 <anteaya> whew
14:24:16 <dhellmann> ttx: what would trigger 2?
14:24:49 <ttx> dhellmann: no I mean, send the announce on tag, like we did in mitaka, but fixing the diff issue
14:25:07 <ttx> even if that means sending emails out a bit early
14:25:35 <ttx> 1/ or 2/
14:25:37 <dhellmann> oh, sorry, you were summarizing the options, I thought you were summarizing what we were going to do
14:25:49 <dhellmann> 1 is easier, but I like 2 better
14:26:13 <dhellmann> thoughts?
14:26:14 <ttx> ok, let's go for (2) and drop the idea of somehow silencing announces until everything is ready
14:26:30 <dhellmann> k
14:26:35 <dhellmann> process changes
14:26:36 <ttx> which would be weird (we announce -intermediary-released ones)
14:26:59 <dhellmann> right, that's why I like 2 better -- fewer special cases
14:27:13 <ttx> ACL changes are almost ready, that's next topic
14:27:20 <dhellmann> ttx, you have an item for the acl changes later on the agenda, so I was going to skip going into details for now
14:27:22 <dhellmann> ok?
14:27:29 <ttx> yes
14:27:33 <dhellmann> right, then: reno
14:27:51 <ttx> dhellmann: what in that do we absolutely need before end of cycle ?
14:27:56 <dhellmann> I spent 2 afternoons this week working on the setuptools integration. It works, but tox can't install reno to run the tests without some nasty hacks to tox.ini
14:28:07 <ttx> are those all nice-to-haves ?
14:28:21 <dhellmann> I was hoping to get the release notes into sdists, but it's not a requirement
14:28:41 <dhellmann> the rest of that is all nice-to-have, though the i18n team will likely be upset if we don't get the translations working
14:29:04 <ttx> ok, let's do them best-effort
14:29:09 <dhellmann> right
14:29:14 <dhellmann> next up: automation
14:29:24 <ttx> I think the other items have precedence
14:29:30 <ttx> (over reno)
14:29:32 <dhellmann> as we said earlier, we're just waiting for some patches to land before we can run another set of tests there
14:29:45 <dhellmann> yes, I agree, the automation is more important (this stuff is just listed in the order it showed up in the planning doc)
14:30:03 <ttx> for me prio 1 is tools / process / automation
14:30:20 <dhellmann> I've added NTH to the automation items I think are nice to have
14:30:26 <ttx> since we need (or would really really like to have) for newton
14:30:56 <dhellmann> what would have to change to automate announcements of release candidates? are we actually skipping those or does it just not work?
14:31:45 <ttx> dhellmann: My position on RCs is that we should not announce them on -announce. We /can/ announce them on -dev
14:32:02 <dhellmann> ok, so we would need to force the "to" address in that case
14:32:16 <dhellmann> that seems like a NTH, assuming we're not doing any automated announcements now
14:32:41 <ttx> dhellmann: yes, NTH -- RCs would need to use a different template though (so that they are not "released"
14:32:52 <ttx> so it's a bit painful to do
14:33:00 <dhellmann> ah, right, I think the announce job restricts which sorts of tags it pays attention to
14:33:04 <ttx> could be ocata material
14:33:07 <dhellmann> yeah
14:33:11 <dhellmann> moving on then
14:33:13 <ttx> currently we send them manually on RCs
14:33:30 <dhellmann> right, I think that's why I wanted to automate it :-)
14:33:31 <ttx> saying it's out, it will be the final if you don't scream, please test"
14:33:47 <dhellmann> the template is a lot simpler, since it doesn't include all of the changes
14:34:05 <dhellmann> I think I had in mind an entirely new job and new script
14:34:24 <dhellmann> the requirements team election started today, thank you anteaya!
14:34:30 <anteaya> thank you dhellmann
14:34:32 <anteaya> :)
14:34:43 <dhellmann> I think that will give them time to set up the request to become official before the summit
14:35:13 <dhellmann> and I think that's it for the priority items
14:35:31 <ttx> so we should have assignees for all the non-NTH
14:36:18 <ttx> lgtm
14:36:19 <dhellmann> I'll look at the announce script, since we're going to defer the reno work
14:36:32 <dhellmann> and the documentation task, too
14:37:10 <dhellmann> ok, I think we have owners for everything then
14:37:25 <dhellmann> ttx, are you ready to talk about the acl stuff?
14:37:31 <ttx> yes
14:37:37 <dhellmann> #topic gerrit acls for release
14:37:57 <ttx> The ACL change merged and Gerrit groups (*-release-branch) are all created and owned by release managers
14:38:12 <ttx> Now I have a small implementation question
14:38:30 <ttx> post-release it's pretty clear, the thing is owned by *-stable-maint
14:38:50 <ttx> pre-release it's less clear, we want it owned by PTLs/release liaisons
14:39:04 <ttx> + probably Release Managers
14:39:24 <ttx> There are a number of existing groups that are "PTLs+Release liaisons" already
14:39:33 <ttx> one are the $PROJECT-release groups
14:39:42 <ttx> the others are the $PROJECT-milestone groups
14:39:55 <ttx> I thought we should reuse one of those rather than create a 3rd variant
14:40:03 <dhellmann> I like $PROJECT-release for this
14:40:05 <ttx> $PROJECT-release is a better name
14:40:12 <anteaya> do folks still need -milestone groups?
14:40:29 <dhellmann> anteaya : I'd have to look, but I don't think so.
14:40:33 <anteaya> I had thought we had gotten rid of -milestone in favour of release
14:40:39 <ttx> There are a number of weird cornercase usage in random ACLs, like "Create branch"
14:40:51 <dhellmann> ttx: we should schedule something for the countdown emails for projects to make sure their groups have the right members
14:41:02 <ttx> Also some groups are too permissive or do not contain the right folks but we can get that fixed between now and when we'll use it
14:41:22 <ttx> anteaya: -milestone is still used in some corner ACLs
14:41:29 <anteaya> ttx: thank you
14:41:29 <ttx> (sahara, zaqar, designate, murano, neutron, keystone, mistral)
14:41:45 <ttx> dhellmann: so -release is not perfect but -milestone is even worse
14:41:55 <ttx> I propose I seed the groups with -release
14:42:00 <dhellmann> yes, and creating yet a third group will be even worse
14:42:01 <ttx> and then we clean up
14:42:10 <dhellmann> ttx: good plan
14:42:24 <ttx> dhellmann: second question, do we want release managers in the pre-release groups
14:42:33 <anteaya> let's also let AJeager know, so he can review new patches with this in mind
14:42:34 <anteaya> yeah?
14:42:39 <ttx> anteaya: ack
14:42:41 <ttx> will do
14:42:45 <anteaya> thanks
14:43:02 <ttx> we could add release managers to -release-branch pre-release, or we can add release managers to -release
14:43:03 <dhellmann> ttx: probably, to help, but we want to make it clear that we're not going to be reviewing lots of patches
14:43:18 <ttx> probably better to add us to -release-branch then
14:43:26 <ttx> (and remove us when post-release
14:43:27 <dhellmann> yes, that would do it
14:43:35 <ttx> ok, I'll have to tweak the script a bit
14:43:44 <ttx> (currently it just adds release managers all the time)
14:45:15 <ttx> OK, I think I have a plan
14:45:34 <dhellmann> ok
14:45:38 <ttx> I'll seed -release-branch with RMs + -release today to test my script
14:46:02 <dhellmann> sounds good
14:46:42 <dhellmann> I added a doc task for this, too
14:47:00 <dhellmann> is there anything else for that?
14:47:04 <ttx> We shoudl copy all the actions to the plan page somewhere, rather than only have them in the meeting notes
14:47:17 <dhellmann> yes, I'll do that after the meeting
14:47:26 <dhellmann> I'll update the priorities, too
14:47:30 * ttx moves actions to the cycle status check paragraph just above
14:48:02 <dhellmann> ++
14:48:45 <ttx> ok done
14:49:00 <dhellmann> ok
14:49:04 <dhellmann> #topic governance reviews related to release
14:49:12 <ttx> I found two reviews of interest
14:49:18 <dhellmann> the first one looks like it needs some discussion about which model to use
14:49:20 <ttx> https://review.openstack.org/#/c/350504/1
14:49:40 <ttx> yes just wanted to raise profile
14:49:52 <ttx> https://review.openstack.org/#/c/351433/1
14:49:52 <dhellmann> if they aren't going to tag, it seems like release:none is ok. that does not preclude stable branches
14:50:04 <ttx> second one is just a repo split
14:50:20 <dhellmann> yeah, that's going to mean updating deliverable files in the releases repo, too
14:50:22 <ttx> which since they were using -intermediary is painless
14:50:30 <ttx> BUT we need to split the files, yes that
14:50:48 <dhellmann> when I suggested setting the type, I didn't realize it was part of the same deliverable
14:51:03 <dhellmann> but it's not a big deal, we just need to split the deliverable
14:51:16 <ttx> ack yes
14:51:40 <dhellmann> so far there's only a mitaka file, so it won't be much work
14:52:02 <dhellmann> so +1 on the gov change, and I can do the deliverable change when that merges
14:52:55 <dhellmann> and comment left on the otherone
14:53:01 <dhellmann> #topic open discussion
14:53:08 <dhellmann> is there anything else to go over this week?
14:53:21 <ttx> nope, I'm away Mon-Thu
14:53:32 <ttx> so someone else (again) will have to take my release day :/
14:53:44 <dhellmann> ok, we can cover
14:54:08 <ttx> oh, one thing
14:54:20 <ttx> there is no mistral-release group
14:54:52 <dhellmann> we can create it, though, right?
14:55:01 <ttx> fungi: is that something that can be added ?
14:55:12 <ttx> dhellmann: not sure as they usually derive from usage in ACL files
14:55:52 <dhellmann> so it would be created empty after the patch to set up the acls for stable/newton?
14:56:05 <ttx> unfortunately no. It's used only indirectly
14:56:14 <dhellmann> oh, right
14:56:18 <ttx> ACL uses -release-branch, which points to -release pre-release
14:56:28 <ttx> (and to -stable-maint post-release
14:56:35 <dhellmann> right, so it's not directly mentioned
14:56:53 <dhellmann> this won't be the only time this comes up, so we should include this in the procedures list
14:57:33 <dhellmann> I'll add that as an action
14:57:36 <ttx> ok, I'll chase down infra to solve that one, please endmeeting
14:57:51 <anteaya> some gerrit acl file would have to mention the group
14:57:58 <anteaya> in order for it to be created
14:58:32 <ttx> ok, so that is a problem with the indirection approach to the problem
14:58:41 <ttx> I'll take that offline
14:58:50 <dhellmann> yeah, I'm sure that can be solved
14:59:14 <dhellmann> well, we're about out of time and I think we've covered anything, so I'll close us out
14:59:19 <dhellmann> thank you, everyone!
14:59:27 <fungi> ttx: sorry, got sidetracked fixing something. reading
14:59:54 <fungi> ttx: yeah, we can add a mistral-release group manually
15:00:18 <ttx> fungi: that would be great, I need to add it to mistral-release-branch
15:00:25 <dhellmann> good
15:00:26 <ttx> we can solve group members another day
15:00:48 <ttx> (though adding mistral(s PTL in it wouldn't hurt
15:00:48 <dhellmann> ok, times up, so I'll clear the room for the next meeting
15:00:55 <ttx> cheers
15:01:00 <dhellmann> thanks again, everyone
15:01:01 <dhellmann> #endmeeting