14:01:20 #startmeeting releaseteam 14:01:21 Meeting started Fri Jan 22 14:01:20 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:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:24 The meeting name has been set to 'releaseteam' 14:01:37 #info this is week R-11 14:01:45 our agenda is in the etherpad as usual 14:01:46 #link https://etherpad.openstack.org/p/mitaka-relmgt-plan 14:02:05 #topic ttx to review release models for obvious errors 14:02:23 wow, lots of discrepancies 14:02:27 had a bit of a fun moment this morning going through them all 14:02:31 soo 14:02:45 monasca is completely off 14:03:05 sigh 14:03:05 it has a large monasca deliverable in milestones mode 14:03:21 but it releases piecemeal with different version numbers 14:03:40 *and* of course doesn't sync openstack/releases 14:03:52 looks like they need "the talk" 14:04:02 shall we draw straws? 14:04:15 I'm away next week 14:04:22 ok, I'll get in touch with rolland 14:04:38 #action dhellmann talk to monasca team about releases 14:04:45 next, we have a few neutron stadium projects 14:05:01 which use the milestones model, except they missed m1 and m2 14:05:22 networking-ovn, octavia, vmware-nsx 14:05:42 those should probably just switch to intermediary 14:05:49 yeah, I don't know if that makes them cycle-with-intermediary or just that they've missed a deadline 14:05:59 we should ping mestery and align 14:06:21 A few things did mitaka-1 but missed mitaka-2 14:06:40 That would be *astara* and murano-apps 14:06:50 could be harmless 14:07:02 #action dhellmann talk to mestery about networking-ovn, octavia, vmware-nsx 14:07:05 is cycle-with-intermediary but did milestones: freezern searchlight and aodh 14:07:15 fix for freezer is already in 14:07:30 ok, I'll propose changing the tags for those others 14:07:40 yeah, and get the ptl +2 14:07:44 #action dhellmann change searchlight and aodh to cycle-with-intermediary 14:07:55 maybe we should add some validation for tag type and release model 14:08:05 I didn't want to do that, but I haven't been doing the manual checking either 14:08:37 then there is a bunch of "intermediary" projects that haven't done a release yet. Probably nothing to worry about, but we should keep an eye on those 14:08:45 we kinda want at least one 14:09:18 if senlin just posted an m2, they got the wrong model, too 14:10:08 we have three that are still marked independent but may want to be intermediary to be able to say "mitaka": magnum, cue and rally 14:10:30 I pinged Adrian yesterday and he said he would do it 14:10:35 but still nothing 14:10:45 I left a comment on the senlin release request 14:11:06 ok, I think the magnum team has had enough opportunities 14:11:11 finally, we have a few that follow cycle, did tags but did not have the corresponding releases change 14:11:44 so they tagged, but didn't file an update in the releases repo? 14:11:57 I think we'll have those as long as we don't reclaim tagging rights 14:12:04 yeah 14:12:08 yeah, I'm not too worried about that 14:12:34 I really want to get the automation done so we can just use the repo for all releases starting next cycle, but this cycle we're going to have missing info 14:12:53 I'll send a general email, though 14:13:07 for magnum if they file before the end of my day today I'll take them -- takes time to go through the governance repo anyway 14:13:10 #action dhellmann send email encouraging independent projects to record their releases in the releases repository 14:13:29 ttx: yeah, I told everyone else the deadline was yesterday 14:13:31 dhellmann: alternatively we could just take away tagging perms 14:13:44 how many times have you had to ask magnum to fix their settings? 14:13:53 that would avoid crazy tags like 2.0.0b2 14:13:54 take away perms from whom? 14:14:12 official project teams 14:14:23 force them all to go through the repo 14:14:25 so far we've only done that for managed projects, but we could think about extending it to all official projects 14:14:36 magnum ? I think 3 times 14:14:53 the -dev email, a personal email, irc ping 14:15:02 did you go to their meeting? 14:15:05 *didn't 14:15:48 oh yes, that too 14:15:56 so 4 14:15:57 so 4 14:16:06 we could also fix it for them 14:16:11 since they said yes 14:16:18 did they file a release request for m2? 14:16:25 I suppose we could 14:16:28 they are intermediary 14:16:39 ah, ok 14:16:43 they said yes in the logged meeting 14:16:46 yeah, let's just fix it for them 14:16:53 I'll file it 14:16:54 I didn't realize we'd had a response at all 14:16:55 ok 14:17:12 #action ttx to file the magnum fix today 14:17:31 they don't have the managed tag, do we need to add that or do they want to stay unmanaged? 14:17:38 so I'll put in bold things we need to fix IMHO 14:17:54 stay unmanaged, they are not eeven cose to being responsive enough 14:17:56 close* 14:18:03 yeah 14:18:41 I would ignore the rest for the time being 14:19:00 missed m2, no big deal, will tell them a lesson 14:19:03 yeah, I'll send email encouraging intermediary projects to file releases if they haven't already 14:19:12 no release yet for intermediary: not yet time to panick 14:19:25 and the ones who forgot to publish to releases repo 14:19:34 cue and rally as independent -- they don't really claim to make a mitaka release so I'm fine with that 14:19:35 but I won't try to chase down individual liaisons 14:19:56 and the things which don't publish to releases... that's bound to happen all the time 14:20:03 until we take away tagging 14:20:10 right 14:20:21 cue and rally are both independent, so that's fine 14:22:14 alrighty 14:22:19 I think I should script this 14:22:27 or develop a check test 14:22:47 yeah, let's add some tests to the validator in the repo 14:23:19 no beta tags unless they have cycle-with-milestones and release:independent can't be in a named series directory 14:23:29 yep 14:24:28 it would also be useful to have a script to scan all cycle-with-milestone projects to find ones that haven't added a given beta tag (with an input like "mitaka 2") 14:24:51 that's more complex, though, and the checks are more important 14:25:33 we do have some release requests for intermediary projects that haven't been processed. I was going to wait and do those Monday, to avoid introducing new versions of libs into the already overloaded gate. 14:26:04 the same for the liberty stable releases 14:26:13 yep 14:26:28 I only caught the most obvious stuff here 14:26:44 #info waiting for monday to release cycle-with-intermediary projects to avoid introducing new libs into the gate 14:26:53 #info waiting for monday to tag liberty stable releases 14:27:10 alright, is there anything else we need to discuss about the milestone? 14:27:46 not really 14:27:46 #topic Release tag changes 14:27:57 #link https://review.openstack.org/#/c/259392 (sahara-test) 14:27:57 #link https://review.openstack.org/#/c/269858 (manila-ui) 14:27:57 #link https://review.openstack.org/#/c/271203 (freezer) + deliverable issue 14:27:58 https://review.openstack.org/271318 <-- magnum change 14:28:03 do those just need reviews? 14:28:14 and maybe a bit of discussion 14:29:01 shall we do that now? or in the reviews? 14:29:20 no hurry 14:29:32 I just wanted to flag them to attention 14:29:37 ok, I'll leave some comments today 14:29:44 oh, on the freezer one 14:30:01 they declared two deliverables, but I think it should be one 14:30:12 freezer and freezer-api 14:30:20 ah, right, I saw that discussion 14:30:21 I'll file a follow-up 14:30:40 it would be more consistent with how other services show up 14:30:51 I wonder if they were concerned about the type:service tag not being right for the freezer repo? 14:31:14 I can't remember, can we have repo-specific tags? or just for deliverables? 14:31:31 deliverables 14:31:45 #action dhellmann file governance change to merge freezer deliverables for consistency 14:31:48 it's basically the same thing, split across a number of repos 14:31:55 yeah, that's what it seemed 14:32:09 as it stands, only freezer-api would have the service tag 14:32:15 we should add a check for that, too -- things in the governance repo as a deliverable should be in the same deliverable in our repo 14:32:35 but the way everyone else does it is to ship the api node together with the other nodes 14:32:39 although that might cause problems when someone adds a new repo 14:32:52 that way the "service" also happens to be the main repo 14:32:55 that makes sense 14:32:59 err.. deliverable 14:33:19 anyway, more consistent to bundle them. 14:33:24 noted 14:33:32 and if they follow milestones, an easy constraint 14:33:50 since they already release at the same time 14:33:56 with same version number 14:34:06 you can merge https://review.openstack.org/#/c/271203/1 and https://review.openstack.org/#/c/269858/1 and I'll file that follow-up 14:34:11 I need to look at the other 2 more closely 14:34:21 oh, wait, https://review.openstack.org/#/c/271318/1 looks fine 14:34:32 so it's just the sahara-tests thing I need to look at 14:34:47 271203 I'll have to wait for the official cooling period 14:35:03 269858 same 14:35:05 hmm, ok 14:35:24 only the sahara one is old enough I think 14:35:46 that one has vulnerability:managed with no comment from fungi 14:36:07 oh, actually, a previous version has a -1 14:36:14 yeah which is why I left it standing 14:36:51 ok 14:37:02 so let's move on 14:37:05 i can refresh my -1 if needed 14:37:20 fungi : good idea, I left a non-voting comment 14:37:27 #topic URL structure of releases.openstack.org 14:37:48 I filed some infra changes to move docs.o.o/releases to releases.o.o/ 14:38:06 then I saw ttx comment somewhere (email chain or IRC, I'm not sure) about having signed tarballs on the same subdomain 14:38:38 I wonder if that means we need to make any changes to the move I've already proposed? or if it would be fine to have releases.o.o/downloads (or something) coming from somewhere other than the openstack/releases repository? 14:38:43 did I? 14:38:59 yeah, that's why I wanted this on the agenda today, it came up this week 14:39:15 it's very likely I just misunderstood what you were saying 14:39:29 I think it's fine to have links to tarballs.o.o in releases.o.o 14:39:51 especially since there are a lot more tarballs than there are releases 14:39:56 #link http://lists.openstack.org/pipermail/openstack-dev/2016-January/084548.html 14:40:01 ttx: that was your comment ^^ 14:40:11 "We are working on moving all that to https://releases.openstack.org and implement artifact GPG signing as well." 14:40:27 oh, I didn't mean moving tarballs 14:40:28 maybe by "all that" you just meant the launchpad milestones? 14:40:38 yeah, "release links" 14:40:45 ok, cool, I just misunderstood then 14:40:49 that's why I wanted to clarify :-) 14:40:59 oops sorry 14:41:08 I can see how that was confusing 14:41:27 all that = docs.o.o/releases 14:41:48 and the links within, not the tarballs themselves 14:41:49 ok, so we'll continue with the existing plan 14:41:55 dhellmann: +1 14:42:31 #link https://review.openstack.org/#/q/topic:releases-openstack-org 14:42:33 for anyone following along 14:43:17 #topic open discussion 14:43:23 that's all we have on the agenda, is there anything else we need to talk about? 14:43:32 about url structure, we could avoid the "releases" redundancy 14:43:37 ttx: are you out next friday? we can skip the meeting 14:43:50 yes, the proposal is to publish to the root of releases.o.o 14:43:58 releases.o.o/mitaka instead of releases.o.o/releases/mitaka 14:44:02 right 14:44:15 hmm 14:44:16 I need to fix the existing patch to use the proper publisher, but that's the goal 14:44:41 currently we have docs.o.o/releases/releases/mitaka so I was wondering how many levels that would remove 14:44:55 oh, I see what you mean 14:45:02 I bet we'd keep one 14:45:06 yes, it will 14:45:11 we can remove the other with a patch in our own repo 14:45:20 yeah 14:45:26 that would look better in links 14:45:29 though maybe we want that to be "series" instead of "releases" 14:45:32 and keep the level 14:45:38 that way we can have "schedules" etc. 14:45:50 the issue is we have schedules/ 14:45:55 or I guess we could put the schedule in the series dir 14:46:07 so /mitaka/index.hml and /mitaka/schedule.html 14:46:11 and instructions.rst 14:46:25 yeah 14:46:38 ok, I'll work on reorganizing the content where it is 14:47:03 we need to do that before we communicate those urls too much 14:47:08 #action dhellmann reorganize releases repository to clean up urls 14:47:11 yeah, I'll do it today 14:47:11 are stuck with them :) 14:47:46 that said the urls I just send for m2 point to releases/releases/mitaka 14:47:46 I can leave some stub pages in place for now, that we can delete later 14:47:49 "this page moved to ..." 14:48:04 yeah , would win extra points 14:48:15 and we can delete them after we move to the new subdomain 14:48:42 sorry I"m not signing up for a lot of work because I'll likely not be able to do any next week ;) 14:48:53 yeah, no problem, it will give me something to do ;-) 14:49:12 feel free to procrastinate and assign me again next week. 14:49:20 noted 14:49:57 I'll be on a plane at meeting time next week 14:50:08 ok, so we'll skip the meeting next week 14:50:10 or in a car just out of a plane 14:50:18 fine by me 14:50:19 #action dhellmann announce no release team meeting next week 14:50:45 if that's all we need to discuss, I'll use the remaining 10 minutes to file some of those patches 14:50:56 and me to pack 14:51:03 enjoy the off-site! 14:51:06 ttyl! 14:51:16 #endmeeting