21:00:25 <mriedem> #startmeeting stable
21:00:25 <openstack> Meeting started Mon Feb 15 21:00:25 2016 UTC and is due to finish in 60 minutes.  The chair is mriedem. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:28 <openstack> The meeting name has been set to 'stable'
21:00:39 <tonyb> mriedem: howdy
21:00:40 * mriedem waits for the masses
21:00:57 * tonyb is always here ;P
21:01:28 <mriedem> i know HPE has today off for a holiday so some people will be gone
21:01:39 <mriedem> there isn't a ton to go over
21:02:04 <mriedem> anyway, let's just start and people can roll in, or not
21:02:07 <mriedem> #link agenda https://wiki.openstack.org/wiki/Meetings/StableTeam#Agenda
21:02:15 <mriedem> #topic status
21:02:24 <mriedem> #link stable tracker https://etherpad.openstack.org/p/stable-tracker
21:02:46 <mriedem> for the periodic stable jobs, i've mostly noticed the trove failures
21:02:48 <mrunge> o/ sorry for being late
21:02:55 <mriedem> which for kilo there is the change here https://review.openstack.org/#/c/276934/
21:03:00 <mriedem> mrunge: o/
21:03:06 <tonyb> mriedem: Yeah and that's blocked by somethign else but I don't recall what.
21:03:10 <mriedem> ^ looks like it just needs some project-config love
21:03:24 <mriedem> tonyb: you said in there trove services weren't running so no tests ran and it puked
21:03:31 <tonyb> .... Oh yeah the gate config on kilo is wonky they asked for help figuring out why
21:03:32 <mriedem> sounds like the sahara thing with devstack plugins
21:03:37 <mriedem> i put a comment in there
21:03:54 <tonyb> mriedem: Yeah It just hasn't bubbled up yet
21:04:37 <mriedem> there was a new thing on my radar today
21:04:46 <mriedem> stable/liberty https://bugs.launchpad.net/oslo.service/+bug/1529594
21:04:46 <openstack> Launchpad bug 1529594 in oslo.service "[stable/liberty] gate-tempest-dsvm-neutron-src-oslo.service fails with "ContextualVersionConflict: (oslo.service 0.9.1.dev6 (/opt/stack/new/oslo.service), Requirement.parse('oslo.service>=0.12.0'), set(['oslo.messaging']))"" [High,Confirmed]
21:04:57 <mriedem> oslo.service on stable/liberty is running one of those -src- jobs,
21:05:09 <mriedem> that blows up with a version conflict with oslo.messaging due to upper-constraints
21:05:23 <tonyb> We need to think hard about the value of the -src- jobs in stable
21:05:31 <mriedem> for now i've just proposed that we exclude the job from stable/liberty for oslo.service since it's fundamentally broken https://review.openstack.org/#/c/280328/
21:05:42 <mriedem> tonyb: yeah, at least stable/liberty
21:05:57 <mriedem> i put alternatives in that change
21:06:02 <mriedem> neither are great
21:06:19 <tonyb> mriedem: That's the second time we've seen liberty, -src- jobs and constrainst just fail to get along.
21:06:20 <mriedem> what i'd like to do is just cap oslo.messaging in stable/liberty<2.6.0
21:06:32 <mriedem> but i feel like people will freak out if i propose that
21:06:39 <tonyb> I *think* we could modify the job to edit-constrainst but that might not work
21:07:10 * tonyb will read the commit message
21:07:13 <mriedem> well, even if that does work, does it reflect reality?
21:07:27 <mriedem> we can do all sorts of things to make tests pass
21:07:58 <mriedem> but the fact is oslo.service<0.12.0 won't work with oslo.messaging 3.0.0, which is what's in u-c on stable/liberty
21:08:14 <mriedem> anyway, let's move on
21:08:24 <mriedem> i think we're just going to keep whacking these moles
21:08:46 <tonyb> Yeah probably
21:08:49 <mriedem> the other kilo thing was your fixtures bug https://bugs.launchpad.net/python-fixtures/+bug/1542984
21:08:49 <openstack> Launchpad bug 1542984 in Python Fixtures "fixtures 1.2.0 isn't compatible with testtools 2.0.0" [Undecided,New]
21:09:04 <mriedem> tonyb: did you want to threaten lifeless on that again or should i this time? :)
21:09:25 <tonyb> mriedem: Yeah I'll try to get his attention today.
21:09:31 <mriedem> ok, cool, thanks
21:09:39 <mriedem> #action tonyb to talk to lifeless about fixtures bug https://bugs.launchpad.net/python-fixtures/+bug/1542984
21:09:46 <tonyb> if I don't get traction I'll lean on you
21:09:51 <mriedem> ok
21:09:56 <mriedem> #topic previous agenda items
21:10:00 <mriedem> #undo
21:10:01 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x9775610>
21:10:05 <mriedem> #topic previous action items
21:10:11 <mriedem> mrunge to follow up on server projects (e.g. horizon) being released to pypi from stable branches
21:10:22 <mriedem> i can't remember what there was to follow up on there
21:10:40 <mrunge> uhm, there was a mail from dhellmann on openstack-dev
21:10:41 <mrunge> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086183.html
21:10:56 <mrunge> it was about the announcement of server packages to pypi
21:11:05 <mriedem> oh, so that was just a bug and doug fixed it
21:11:09 <mrunge> exactly
21:11:13 <mriedem> ok, cool
21:11:23 <mriedem> moving on
21:11:24 <mriedem> mriedem to nudge mistral stable CPL to update https://review.openstack.org/#/c/273223/
21:11:36 <mriedem> that's done, there was another change that needed reverting
21:11:43 <mriedem> now i'm +1 on the mistral 1.0.1 release request
21:11:55 <mriedem> mriedem to follow up with mestery and/or ihar on releasing from stable more often if they are going to backport a lot of changes frequently
21:12:01 <mriedem> also done http://lists.openstack.org/pipermail/openstack-dev/2016-February/086158.html
21:12:16 <mriedem> mestery is going to do more frequent stable neutron release requests
21:12:30 <mriedem> mriedem to update the stable policy with what it means to be actively maintaining stable branches for a project
21:12:37 <mriedem> i have that patch here: https://review.openstack.org/#/c/280372/
21:12:43 <mriedem> so reviews appreciated
21:12:57 <mriedem> ^ is actually part of a series that cleans up some of the stable branch docs
21:13:06 * dims_ peeks
21:13:39 <tonyb> mriedem: I'll look at them today
21:13:45 <mriedem> thanks
21:13:46 <mrunge> in the past, we had issues with string changes in backports
21:13:47 <mriedem> it's pretty simple
21:14:04 <mrunge> i.e. string change == not allowed for backports
21:14:13 <mriedem> mrunge: is that just horizon?
21:14:20 <mriedem> b/c now the translation stuff happens on stable branches also
21:14:21 <mrunge> hmm, yes and no
21:14:23 <mriedem> at least for stable/liberty
21:14:33 <mrunge> exactly. it's not that simple any more
21:14:57 <tonyb> Yeah if you change a transtalted string you loose all the translations :(
21:14:59 <mrunge> client packages and even server packages now have translations
21:15:00 <mriedem> does horizon key off the translations or something? i think doug-fish has tried explaining it to me once.
21:15:15 <tonyb> but at least on liberty they can be re-translated
21:15:21 <mriedem> tonyb: yeah
21:15:34 <mrunge> I wonder if we should have something about translations in the guide
21:15:48 <mrunge> as this is somehow unknown
21:15:55 <mriedem> mrunge: if you think something is missing feel free to push up a change to add it in the review guidelines
21:16:08 <tonyb> +1
21:16:10 <mrunge> ack
21:16:11 <mriedem> i know sometimes new translatable strings are backported, but that's less of an issue in my mind
21:16:27 <mriedem> usually new exceptions or something
21:16:37 <mrunge> I have an issue with "sometimes"
21:16:48 <mrunge> i.e that's not a clear rule
21:16:48 <tonyb> We shoudl probably ask Daisy
21:16:49 <mriedem> so you don't ever want them?
21:17:11 <mrunge> twofold: yes for as many as possible
21:17:12 <mriedem> it's definitely a different animal for horizon
21:17:33 <mriedem> if your page is all chinese and then you have some english show up
21:17:50 <mrunge> and no: as it makes backporting complicated: you can not guarantee a to have a translation backport
21:17:56 <mriedem> in the server projects it might be a logging statement or something that doesn't get back to the end user
21:18:18 <mrunge> https://github.com/openstack/neutron/tree/master/neutron/locale
21:18:25 <mrunge> that's translations for neutron
21:18:36 <mrunge> just to illustrate, it's not only horizon
21:18:41 <mriedem> yeah i know
21:18:49 <mrunge> ok.
21:19:08 <mriedem> but my point is, if nova backports a new i18n string that is like a warning log in the service logs, i don't have a problem with that
21:19:23 <mriedem> it's a bigger issue for horizon
21:19:27 <mrunge> ah, ok. that's different
21:19:30 <mrunge> I get you
21:19:51 <mriedem> new rest api response exception messages, that's something we'd have to think about
21:19:52 <mrunge> let's iterate over patches
21:19:54 <mriedem> sure
21:20:03 <mriedem> ok, last action item from last week
21:20:03 <mriedem> ttx to propose corresponding governance review
21:20:09 <mriedem> that's here: https://review.openstack.org/#/c/277918/
21:20:22 <tonyb> brb
21:21:03 <mriedem> there is already a fun issue bubbling up in that one, which is, if a project has stable branches that wouldn't pass the policy (backported features or something), but then wants to get the follows-policy tag, when do they get the tag? say stable/kilo is bad and stable/liberty+ is good
21:21:10 <mriedem> do they not get the tag until stable/kilo is gone?
21:21:18 <mriedem> since tags don't have any metadata on them, like a since:liberty meta
21:21:27 <mrunge> heh
21:21:33 <mriedem> anyway, flaper87 raised that point, so we're discussing in the change
21:21:58 <mriedem> in practice i don't think it's probably going to be a huge issue once the tag is rolled out
21:22:14 <mriedem> i have a feeling that projects which have messy stable branches are going to take awhile to get used to following policy anyway
21:22:27 <mriedem> #topic release news
21:22:44 <mriedem> this is just a reminder to stable CPLs to think about stable/liberty release requests around the time of m-3
21:22:48 <mriedem> per dhellmann's email http://lists.openstack.org/pipermail/openstack-dev/2016-February/086362.html
21:23:24 <mriedem> #info consider stable/liberty point releases around m-3 per http://lists.openstack.org/pipermail/openstack-dev/2016-February/086362.html
21:23:39 <mriedem> no stuck reviews so i'm skipping that
21:23:48 <mriedem> i don't think we have any updates on tooling, so skipping that
21:24:00 <mriedem> #topic open discussion
21:24:05 <mriedem> does anyone have anything?
21:24:14 <mrunge> nope
21:24:24 <mriedem> and with tony gone, i think that's all
21:24:28 <tonyb> mriedem: just a general observation that not all the stable CPL's hang out in -stable
21:24:44 <mriedem> tonyb: yeah, or by default PTLs
21:25:00 <tonyb> mriedem: Yeah. I don't know if it's a problem
21:25:13 <mriedem> #action mriedem to send a reminder to -dev ML for stable CPLs/PTLs to hang out in #openstack-stable
21:25:15 <mriedem> how's that
21:25:19 <tonyb> then other day I just jumped onto the appropriate project channel and asked for reviews
21:25:22 <tonyb> that worked
21:25:27 <tonyb> :)
21:25:29 <mriedem> yeah that's usually what i do
21:25:48 <mriedem> i think it is an indicator of involvement though
21:25:49 <mrunge> sounds like a sane thing to do
21:26:00 <mrunge> yes
21:26:14 <mriedem> maybe we should add that to my docs patch on what being active means
21:26:18 <mriedem> i'll do that
21:26:40 <mriedem> ok, anything else?
21:26:50 <tonyb> I know that becuase of timezones it's not complete coverage but as you say it's a good indication of investment
21:26:58 <tonyb> mriedem: not from me
21:27:11 <mriedem> ok, will end it. thanks tonyb/mrunge
21:27:15 <mriedem> #endmeeting