15:00:05 #startmeeting stable 15:00:11 Meeting started Tue May 3 15:00:05 2016 UTC and is due to finish in 60 minutes. The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:15 The meeting name has been set to 'stable' 15:00:44 the agenda is old, i wasn't prepared to run this 15:00:48 is anyone around? 15:02:46 o/ 15:02:51 ohi 15:02:55 i was about to quit 15:03:06 heh, sorry about that 15:03:11 dhellmann said he would come too 15:03:25 maybe quick summit postmortem ? 15:03:37 yeah... 15:03:40 o/ 15:03:45 #topic summit recap 15:03:50 #link summit etherpad https://etherpad.openstack.org/p/newton-stable-summit 15:03:58 there were 3 items 15:04:05 Trying to fetch action items for me if any 15:04:08 1. backward compat for libraries 15:04:23 the basic question was, do we care about in-place upgrades? 15:04:35 lifeless also has a dev thread on this 15:05:04 I haven't caught up with email yet, but oslo had a separate session in which we all agreed to support n-1 upgrades in place but not *mixed* upgrades of multiple services 15:05:15 #link lifeless ML thread on backward compat http://lists.openstack.org/pipermail/openstack-dev/2016-April/093403.html 15:05:22 at least that was my recollection, the mixed bit may have been a separate session 15:05:37 yes that's what I heard too 15:05:54 o/ 15:05:58 from the summit session, the notes i have are the TC will take a vote on this and then in general projects won't have to support backward compat. 15:06:02 we were going to have a tc resolution to the effect that the community doesn't need to support mixed upgrades 15:06:04 although several already are 15:06:09 yup 15:06:33 well, not "won't have to support backward compat" but "won't have to support mixed upgrades on a given node" 15:06:58 so some backwards compat is still supported, in a way that makes dependency management significantly simpler 15:07:01 ok, i updated the note in the etherpad 15:07:13 2. stable branch eol policy 15:07:40 #info we decided we're not going to extend stable/kilo another 6 months, it gets messy and sets the wrong expectations - we need to be consistent with EOL 15:07:52 #action tonyb to get an EOL date for stable/mitaka 15:08:02 yeah, my take was that we could seriously consider it starting with liberty though 15:08:14 #action Daviey to freeze stable/kilo this week and plan for the final release 15:08:24 kilo was hard due to non-constraints 15:08:26 ttx: i don't think we agreed to that 15:08:49 mriedem: no we didn't, but that was my read. like "we can't do that with kilo" 15:09:05 ttx: i'll leave it up to you to bring it up in barcelona then :) 15:09:12 ha! 15:09:29 yes, my turn I guess 15:09:44 I don't remember any decision like that about liberty. I thought we agreed being consistent was the important thing. 15:09:48 i'll ping Daviey after the meeting about stable/kilo freeze 15:09:54 dhellmann: yes +1 15:10:24 methinks something should be in the dev list about the stable/kilo eol session 15:10:33 i could take that todo i guess since i started the discussion 15:10:35 ++ 15:10:44 #action mriedem to recap the stable kilo eol policy session in the dev ML 15:11:02 moving in 15:11:03 *on 15:11:10 3. co-installability requirements are holding us back 15:11:25 the only action item in the etherpad was dhellmann wanted a PTL for dependency management 15:11:41 and no one raised their hand 15:11:47 we have a bunch of incremental improvements that folks signed up to help with for testing and the change to the way we sync requirements 15:12:05 and we have a few volunteer reviewers, who we're going to mentor for a few months and then revisit the ptl question 15:12:53 ok 15:13:32 anything else on summit stuff? 15:13:59 #topic status 15:14:11 we had a discussion about mailing list tags for release team stuff, including release announcements 15:14:20 we've been tagging releases from stable branches with [stable] 15:14:40 I wonder if folks following that tag have the same complaint about noise as a result? maybe we should remove that? 15:15:17 i don't have a separate folder for [stable] mail, 15:15:22 i have one for [release] 15:15:28 oh, mriedem you weren't in the room for that, so more context: we had complaints about too many messages tagged [release] with release announcements, so we're going to pick a new name for that tag for automated messages this cycle 15:15:29 but it's mostly a dumping ground 15:15:47 dhellmann: yeah, that's a good idea, because i miss the actual emails about things we need to know about doing releases 15:15:49 or schedules, etc 15:15:54 right 15:16:19 ok, so those will still be [release] and the announcements will be [something else], and I'm wondering if you want us to make the same change for [stable] on stable releases 15:16:33 we could change the tag, or just drop it since the series name is in the subject 15:17:17 if it has [release] in it it doesn't matter to me 15:17:26 ok 15:17:30 i'd probably just drop [stable] from those 15:17:43 ok, I'll make a note to do that, too 15:18:00 i don't really consume those, so i'm not a good person to ask though 15:18:28 I'll confirm with tonyb 15:18:43 thanks. passing the buck is really what i wanted for the outcome here on my part. :) 15:19:26 consider it passed :-) 15:20:01 ok 15:20:11 so we blew up the status part of the meeting, 15:20:17 but i haven't really been watching status due to the summit 15:20:25 all of the periodic jobs failed last night b/c of gate instability 15:20:36 there wasn't anything new in the stable-tracker etherpad 15:20:51 where is that etherpad? 15:20:53 * dhellmann should know this 15:21:00 #link https://etherpad.openstack.org/p/stable-tracker 15:21:16 ty 15:22:01 ok, i don't have anything else 15:22:07 end early? 15:22:14 I have nothing to add 15:22:21 ttx: ? 15:22:39 consider that done then 15:22:40 thanks 15:22:42 #endmeeitng 15:22:44 #endmeeting