10:00:33 #startmeeting stable 10:00:34 Meeting started Mon Nov 28 10:00:33 2016 UTC and is due to finish in 60 minutes. The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 10:00:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 10:00:37 The meeting name has been set to 'stable' 10:01:02 Anyone around for the newly rescheduled and revitalised stable team meeting? 10:01:09 o/ 10:01:33 apevec: Howdy 10:01:34 tonyb, good evening? 10:01:38 o/ 10:01:51 ttx: hi there 10:02:01 apevec: Yeah 2100 here 10:02:10 apevec: hopefully closer to noon for you 10:02:15 (and ttx) 10:02:34 yep 11am 10:03:12 \o/ 10:03:20 Lets get started 10:03:24 #topic status 10:03:45 #link http://status.openstack.org/openstack-health/#/g/build_queue/periodic-stable 10:04:07 networking-odl, networking-midonet, heat are all failing 10:04:37 midonet jobs should be removed 10:04:50 I think they all have inflight fixes so hopefully this time next week we'll be back to the "rock solid" we've come to knwo and live this cycle 10:05:00 yep 10:05:11 apevec: Oh? They're working on a fix 10:05:21 ah them I'm out of date :) 10:05:37 I thought they did not branch newton yet 10:05:53 apevec: Well ihar sent them a polite email saying ... "is there anybody out there" 10:06:01 apevec: Ahh okay 10:06:11 https://review.openstack.org/#/c/402334/ 10:06:24 apevec: that's a point I'll check for that thing after we EOL liberty 10:07:29 apevec: Ahh okay I see, only the *newton* jobs that makes more sense 10:07:55 thread that Ihar started continued: http://lists.openstack.org/pipermail/openstack-dev/2016-November/107946.html 10:08:08 it ended up w/ question for release team about branching procedure 10:08:09 ttx, ^ 10:08:37 yeah, I wanted to wait until dhellmann was back to discuss the details 10:08:43 ack 10:09:31 Hmm somehow I only saw the first message in the thread 10:09:42 * tonyb will need to adjust workflow .... 10:11:43 Anything else for status? 10:12:45 #topic Action items 10:12:54 move this meeting ... check :D 10:13:16 #topic Liberty EOL starting 10:13:43 So last week I sent the lists out of EOL vs non-EOL repos: 10:13:50 #link https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L1 10:14:00 #link https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt-L182 10:14:25 This week I'll start doign the Abandons and tagging (with infra's help) 10:15:01 Do eitehr of you see anything strange in the first list? 10:15:24 It's harder to un-EOL a repo than to EOL one later ;P 10:15:58 tonyb: you're EOLing non-official stuff too ? 10:16:03 .... Oh glance, would like to be EOL'd late this week as they have an important chnage they'd like in liberty 10:17:02 networking-* might need double-check, since they've stadium/non-stadium varieties... 10:17:09 ttx: Yes, it's my understanding that that make things better for infra. 10:17:18 apevec: okay. I 10:17:34 ll poke armax / and Ihar before I do those. 10:17:44 I think GBP projects complained last time? 10:17:45 last time Ihar opted them in 10:17:58 nothing jumps to me as wrong (beyond the pile of non-official projects 10:18:00 ) 10:18:28 apevec: Yes, that was becasue I said I wouldn't EOL them and then did ... because of a process failure. 10:18:30 ok, you have *group-based-policy* on the 2nd (not yet) list 10:19:20 apevec: they also have a repo in the first list ... I shoudl double check 10:19:47 ah yes, I missed that one 10:19:57 apevec: One issue is the GBP gate will be b0rked once we EOL devstack and requirements 10:20:17 yeah, they should be aware of that 10:20:28 btw why deb-* want to keep EOL branch? 10:21:08 apevec: Well they're not getting EOLd or do you mean those tools will fall over once e EOL the branch? 10:22:15 yeah, I wonder how they'll keep it working 10:22:45 also I thought they started later then liberty 10:23:11 zigo, ^ 10:23:21 (we can take it offline) 10:23:45 apevec: spot checking openstack/deb-nova 10:23:46 balder:deb-nova tony8129$ gti branch -va | grep liberty remotes/gerrit/stable/liberty 090bff7 Add error handling for delete-volume API remotes/origin/stable/liberty 090bff7 Add error handling for delete-volume API 10:23:50 balder:deb-nova tony8129$ 10:24:24 tonyb, that's b/c they cloned nova ? 10:24:41 apevec: I think the repos have been on debian infra for $long_time but they took a while to be cloned in to our infra which caused a small problem about 6 months ago 10:24:42 deb work is in debian/* 10:25:03 stable/* are just upstream clones afaict 10:25:13 in deb-* 10:25:15 apevec: Ahh yes so they are 10:25:24 I need to check for debian/* 10:25:30 so they should be removed imho 10:25:33 to avoid confusion 10:25:40 also debian/newton is the only branch 10:25:51 so in this case there isn't a debian/liberty so it shouldn't be a problem 10:26:07 yeap, but let's hear from zigo to confirm 10:26:17 apevec: Yeah I'll try again 10:26:25 (to reach him) 10:28:14 Once the liberty EOL is done I intend to find all the older branches that are still around and try to get permission to clean them up 10:28:54 and after that look for $repos that have mitaka and master branches but no newton branch 10:30:13 any other thoughts on EOLing / cleaning up? 10:30:17 nope 10:30:44 nope 10:30:55 \o/ 10:31:25 #topic Open discussion 10:31:32 o/ 10:31:40 ttx: shoot 10:31:56 Wanted to raise that the release team is interested in having more stable release managers 10:32:14 Basically we can give anyone you bless +2 to the openstack/releases repo 10:32:23 ttx: Ahh so last week apevec and I discussed him doing just that thing 10:32:36 Since we require +2 from a stable team member anyway 10:32:45 ttx: I was goign to bring it up with dhellmann 10:33:12 ttx: I was thinking we'd start with one and test the process / tools and then maybe add a 3rd 10:33:29 sounds like The idea is that the person would agree to only work on stable/* releases 10:33:38 (or would decide to join the releas eteam proper if they want to do more) 10:33:46 ttx: IIRC we were goign to use the honor system rather than complex gerrit ACLs 10:33:51 yep 10:33:55 cool 10:34:13 Just to let you know that I checked and the Gerrit group is already there 10:34:43 https://review.openstack.org/#/admin/groups/977,members 10:34:59 ready to add individual members :) 10:35:12 ttx: awesome! I was just checking that part 10:35:51 ack, I'm fine w/ honor system (and I was in Release Mangers before based on the same system) 10:35:54 tonyb: do you need to stay in the "release managers" group ? Probably if you want to create some tags/branches 10:36:13 (to do EOLing) 10:36:36 at least until we automate that :) 10:36:55 ttx: Yup automation all the way! 10:37:39 ttx: I'm not sure about what permissions I need. I guess that's a discussion to bring fungi in on 10:38:16 tonyb: let's keep it the current way 10:39:07 ttx: Sounds good. We can re-assess at the PTG ;P 10:40:15 #action tonyb to talk to dhellmann about adding apevec to releases-core for stable approvals 10:41:13 anything else? 10:41:23 nothing from me 10:41:24 I'm good 10:41:50 hello, meeting still in the progress? I were asking to help with removing icehouse branches, anyone can help? 10:41:57 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/107754.html 10:42:37 vgridnev: Sure I have an item for December to find those things and clean them up 10:42:46 vgridnev: I can start with yours if you like :) 10:43:00 cool tonyb, thanks 10:43:11 vgridnev: you're very welcome 10:43:53 I wanted to float the idea of includeing constraints support as a pre-req for the stable:follows-policy tag 10:44:37 I think it's reasonable to include it by way of the active-maintence clauses 10:44:59 #link http://docs.openstack.org/project-team-guide/stable-branches.html#active-maintenance 10:45:27 My rationale is that projects that do that thing really are co-installable and generally easier to take care of 10:45:50 thoughts? 10:47:25 sounds good 10:49:19 If there isn't anything else I'll give y'all back 12 mins :) 10:50:36 Thanks everyone 10:50:46 #endmeeting