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