12:00:16 <tonyb> #startmeeting requirements
12:00:17 <openstack> Meeting started Wed Sep  7 12:00:16 2016 UTC and is due to finish in 60 minutes.  The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:20 <openstack> The meeting name has been set to 'requirements'
12:00:51 <tonyb> ping for sigmavirus, number80, dirk, coolsvap, toabctl
12:00:57 <number80> o/
12:01:03 <toabctl> hi
12:01:04 <coolsvap_> o/
12:01:17 <dirk> o/
12:01:58 <tonyb> Let's get started ....
12:02:02 <tonyb> #topic Any controversies in the Queue?
12:02:11 <coolsvap> https://review.openstack.org/#/c/366631/
12:02:22 <tonyb> given we're in freeze things are quiet
12:02:52 <tonyb> coolsvap: what's up with that?
12:02:57 <coolsvap> question : do we need explicit mail on list related to all FFEs?
12:02:59 <dirk> Well, in general there are quite a few uc changes that didn't get in
12:03:10 <prometheanfire> o/
12:03:39 <dirk> So now we have the funny situation that releases.openstack.org says that something has been released for Newton while it is not used for Newton gating
12:03:40 <coolsvap> the commit message indicates the requirement
12:03:49 <dirk> Is that really how we want it?
12:04:04 <toabctl> dhellmann, maybe also interessting for you^^
12:04:12 <dirk> I wonder which version of package should be used for Newton by downstream distribution vendors
12:04:20 <tonyb> coolsvap: Yeah we're supposed to discuss them on the list
12:04:53 <tonyb> dirk: let's come back to that in open discussion
12:05:07 <dirk> Tonyb: ok
12:05:16 <coolsvap> tonyb: thanks I conveyed the message
12:05:20 <prometheanfire> ya, I'm not adverse to bumping the minimum but reason must be given on the mailing list
12:05:43 <tonyb> coolsvap: When we see the message I'll look into the re-release impact
12:05:46 <prometheanfire> next time we should send an email out to the PTLs asking for gr bumps
12:06:24 <tonyb> prometheanfire: Yeah we'll try to do that 2 weeks befoer freeze
12:06:30 <prometheanfire> we have a similiar situation with oslo.db
12:06:49 <sigmavirus> o/
12:06:59 <tonyb> prometheanfire: it'll all depend on the impact of the bump re-releasing 1? 10? 50? packages?
12:07:18 <tonyb> prometheanfire: Yeah I we shoudl talk about oslo.db
12:07:45 <prometheanfire> yep
12:07:57 <tonyb> So the u-c bump seems pretty simple the g-r change less so
12:08:33 <tonyb> it's certainly somethign we can take after we lift the freeze as backporting it to stable would be within the policy
12:08:35 <prometheanfire> yes, for both
12:08:44 <prometheanfire> well, just oslo.db I guess
12:09:06 <prometheanfire> true, we could roll that way
12:09:36 <tonyb> taking the g-r change impacts 40 projects 25 are services so they're more or less okay, 1 is a library so it's not *terrible* to take the bump
12:09:55 <prometheanfire> the main reason I'd put forth on doing it now is to let packagers know, now is the time they start looking/packaging a release (at least I typically do)
12:10:01 <tonyb> the positional change can't be backported so it's now or never
12:10:17 <number80> tonyb: it's actually required (positional 1.1.1)
12:10:36 <number80> we had failures w/ 1.0.1 on our downstream CI with old positional
12:10:51 <dirk> Yep, anything older does not work
12:11:02 <prometheanfire> then we need an FFE on the ML at least
12:11:03 <tonyb> number80: right but positional 1.1.1 is in u-c so that's the recommended package
12:11:28 <tonyb> number80: I agree that we have a correctness issue here
12:11:52 <number80> tonyb: yeah, but most downstream relies on g-r as we can't update everything to what's in u-c
12:12:35 <number80> well, if it contradicts policy, then we can just deny it anyway
12:13:30 <tonyb> I guess we need to see the FFE request then I'll look into the impact
12:13:35 <prometheanfire> I don't think it contradicts policy
12:14:01 <prometheanfire> we need an FFE request maninly (and like tony just said, to look at impact)
12:14:11 <number80> ack
12:14:40 <tonyb> Yeah positional is unlikey to get an FFE as it'll for a re-release of keystone* and oslo.context which will have a heap of knock on releases
12:15:33 <number80> ack, well we fixed that issue downstream, so it's not critical for us
12:15:41 <tonyb> any other controversies?
12:15:52 <number80> bu38
12:15:56 <number80> (sorry)
12:16:01 <prometheanfire> as a packager if I didn't know about this situation I probably wouldn't bump it for newton
12:16:34 <prometheanfire> I have 1.0.1 packaged and don't see a reason to package the new version if it satisfies reqs
12:16:52 <dirk> The alternative would be to make things work again with the old version
12:16:55 <dirk> Not sure it that is easier
12:17:04 <tonyb> prometheanfire: well if you don't package barbican ....
12:17:07 <prometheanfire> number80: was it fixed via a project changing their requirements?
12:17:24 <prometheanfire> tonyb: true
12:18:35 <tonyb> moving on ....
12:18:49 <tonyb> #topic Barcelona Design Summit
12:18:52 <number80> prometheanfire: fixed by updating our positional package and packaging
12:19:18 <prometheanfire> number80: so you don't ensure the new version is installed?
12:19:32 <tonyb> nothing to say really just we've requested a session so we shoudl start deciding what we want to talk about fo 40mins ...
12:20:03 <number80> prometheanfire: we do
12:20:05 <dirk> lessons learned and plans for ocata
12:20:18 <number80> *nods*
12:20:45 <tonyb> dirk: yeah that'd work ;P
12:21:01 <tonyb> #topic mascot
12:21:43 <tonyb> waiting got the 'waterfall' artwork, we get it in Barcelona
12:22:10 <prometheanfire> nice
12:22:25 <tonyb> #topic Coordinating with the release team
12:23:08 <tonyb> Ummm not sure what we need to say here, I think things are working.
12:23:34 <prometheanfire> yep, think so
12:23:36 <tonyb> There was a question ... 'stable branch for openstack/requirements'
12:23:55 <tonyb> Not sure what? ... anyone?
12:24:05 <prometheanfire> ?
12:24:14 <prometheanfire> not sure what?
12:24:19 <sigmavirus> tonyb: maybe someone was confused as to when it would be cut?
12:24:19 <prometheanfire> what are you asking?
12:24:31 <sigmavirus> ¯\_(ツ)_/¯
12:24:46 <dirk> yeah, when is the branch being created I guess is the question
12:24:57 <tonyb> prometheanfire: This was on the agenda I don't know what it's for.
12:25:08 <tonyb> prometheanfire: I was hoping whoever put it there would speak up ....
12:25:19 <prometheanfire> I think it's just a subject
12:25:43 <prometheanfire> when and if cores here have/need access to it are the questions
12:25:51 <prometheanfire> at least how I intrepret it
12:26:17 * coolsvap think it could be the question
12:26:19 <coolsvap> it was on the agenda last week as well
12:26:37 <tonyb> prometheanfire: Oh okay so requirements-core have access to the master branch stable-maint-core has access to the stable/* branches
12:27:14 <tonyb> prometheanfire: We'll look at growing a 'requirements-stable-core' group but that'll be post Barcelona
12:27:48 <tonyb> prometheanfire: does that help?
12:28:02 <prometheanfire> yep
12:28:21 <tonyb> #topic Tasks from Etherpad
12:28:29 <tonyb> #link https://etherpad.openstack.org/p/requirements-tasks
12:28:45 <prometheanfire> completed another one off of 20
12:28:50 <tonyb> we're in freeze so I guess now would ba a good time to curate the list
12:29:07 <prometheanfire> just one more to go, which already has a +2
12:29:14 <tonyb> prometheanfire: nice.
12:30:26 <prometheanfire> next?\
12:30:32 <tonyb> #topic Volunteer for next meeting
12:30:40 <tonyb> - Sep 21
12:31:54 <tonyb> Do we still want to keep rotating this?  I can just take them unless I'm traveling ....
12:32:13 <dirk> I'm fine with tonyb :)
12:32:28 <prometheanfire> worksforme
12:32:29 <coolsvap> fine with me :)
12:32:32 <dirk> I can also be a backup for Sep 21 should you not have time
12:32:49 <tonyb> dirk: Thanks
12:32:52 <prometheanfire> I just don't want to do the 28th
12:33:01 <tonyb> #topic Open Discussion
12:33:10 <coolsvap> tonyb++ just let us know when you are not able to
12:33:15 <prometheanfire> or two weeks in a row, (have to wake up for this) :P
12:33:28 <prometheanfire> tonyb: about positional
12:33:42 <tonyb> dirk?  what was the deal you were talking about
12:33:57 <tonyb> prometheanfire: sure what's new
12:34:07 <prometheanfire> thinking
12:34:18 <dirk> tonyb: sure
12:34:31 <dirk> so, there is a mismatch right now in what is used for gating vs what was released tagged for newtong
12:34:33 <dirk> newton
12:34:35 <tonyb> prometheanfire: Yeah, thinking is good :)
12:34:36 <dirk> consider https://review.openstack.org/#/c/364898/
12:34:52 <prometheanfire> if the 'broken' projects already have the updates in their requirements then I guess it's just a correctness change (as it is now)
12:34:56 <dirk> vs https://releases.openstack.org/newton/index.html
12:35:43 <dirk> that page mentions ceilometerclient 2.6.0 and 2.5.0 as being newton releases
12:35:49 <dirk> but currently uc limits to 2.5.0 iirc
12:36:04 <prometheanfire> uc limits to 1
12:36:13 <dirk> its the case for a whole bunch of releases that happened recently just after the freeze
12:36:16 <prometheanfire> just one release, so it'd be wrong either way
12:36:23 <tonyb> dirk: right but post freeze 2.6.0 will be fine on stable/newton
12:36:39 <prometheanfire> gr bumps are the main thing we worry about
12:36:55 <dirk> well, we need to worry about both imho :)
12:37:06 <dirk> I don't think its good to have releases for newton that are not used for newton gating
12:37:27 <dirk> ceilometerclient might not be the best example in that regard, there is probably a better one
12:37:39 <prometheanfire> then we should branch soon?
12:37:58 <tonyb> prometheanfire: we branch after all the services
12:38:00 <prometheanfire> perhaps we should branch earlier and accept gr updates during the early time
12:38:08 <tonyb> we're always last
12:38:11 <prometheanfire> is there a reason?
12:38:24 <dirk> tonyb: so we plan to do those newton release bumps only on the stable/newton branch?
12:38:46 <tonyb> prometheanfire: Yeah branching early has the potential for drift that is harder to resolve
12:38:55 <dirk> doesn't sound perfect change for a stable branch imho
12:39:01 <dirk> those version bumps could have some downsides
12:39:03 <prometheanfire> ya, keeping it in sync would be harder
12:39:08 <tonyb> dirk: no on master and stable/newton
12:39:13 <number80> ack
12:39:54 <prometheanfire> but I think the overhead of dealing with this is worse atm
12:40:11 <tonyb> dirk: Well it'll be up to $project to request it but it's not impossible we just can't do it now
12:40:17 <dirk> tonyb: sure, ok, master and newton. but that means newton will get changes post relaase that are bigger version bumps
12:40:31 <dirk> tonyb: why can we not do it now? they don't propagate into other projects afaik
12:40:55 <dirk> as long as we are sure that the uc change does not break the gating checks somewhere and release team is aware of it happening it might be okay to do it now I'd think
12:41:23 <toabctl> and we would get testing for the latest newton releases from the different projects.
12:41:26 <dirk> or alternatively there shouldn't be further releases for "newton" done by the release team that are not reflected in uc changes
12:41:55 <tonyb> dirk: They can apply for an FFE ... if the impact is small then fine but 1 idea of the freeze od u-c is to give distros a chance to package all-the-things
12:42:17 <prometheanfire> as a distro I didn't know this
12:42:18 <dirk> tonyb: right.. as a matter of fact I'm part of the distro folks and I don't know what to package :)
12:42:36 <tonyb> dirk: releases are client/library frozen so if there are rleases they'll be for good reasons (like oslo.db)
12:42:39 <prometheanfire> also, as a distro I'd rather see a branch and take from that (it's what I generally wait for)
12:42:39 <dirk> tonyb: should I package what has been tested for newton or should I package what has been released for newton?
12:43:07 <tonyb> dirk: tested, that's part of the commitment behind u-c
12:43:37 <dirk> ok, so packagesr should use uc if possible and not newer releases?
12:43:47 <toabctl> well - for the ceilometerclient example, the new release (not in u-c) is full of bugfixes. I would use that (I'm also packaging for a distro)
12:43:48 <dirk> even if they were released as target for newton?
12:43:53 <prometheanfire> yes, UC is what is tested
12:44:03 <tonyb> dirk: right if it's not in u-c it hasn't been tested so there's a risk
12:44:17 <dirk> tonyb: right, do you want the risk upstream or somewhere downstream?
12:44:30 <dirk> the problem is as a distributor I can always go up a version but I can never go down a version ;)
12:44:46 <prometheanfire> toabctl: I'd probably like that, but we don't always know that
12:44:51 <dirk> so right now I'd have to stick with 2.5.0 even though 2.6.0 is much better judging fromthe commit log
12:45:01 <tonyb> dirk: we'd only go backwards if theer was a problem with $version
12:45:10 <prometheanfire> as a distro I can go forward and back :D
12:45:25 <dirk> prometheanfire: I need a time machine for going back ;)
12:45:42 <prometheanfire> dirk: use gentoo :P
12:45:52 <tonyb> now now ;P
12:45:56 <prometheanfire> anyway, sidetracking
12:46:10 <tonyb> so it seems like there is still some confusion about g-r and u-c
12:46:19 <tonyb> that'd be a good thing to discuss in person
12:46:31 <dirk> tonyb: my suggestion should be that we'd discuss with release team on what to do with those (I think its just 5 or so) releases that came just after the freeze
12:46:31 * prometheanfire wishes he'd go to the summit
12:46:47 <toabctl> os-vif is another example
12:47:16 <dirk> tonyb: well, its not so much about g-r and u-c as about u-c vs what is in the releases.openstack.org database
12:47:16 <tonyb> toabctl: Right ... *cough* FFE *cough*
12:47:43 <prometheanfire> ya
12:47:50 <dirk> tonyb: at one of the previous summits as far as I remember dough and thierry announced that releases is supposed to be used for openstack packaging
12:47:50 <prometheanfire> people should be using that a bit more...
12:47:55 <prometheanfire> FFE that is
12:48:05 <dirk> which is fine by me. I just see that there is a mismatch now for that vs what was tested
12:48:19 <dirk> we can keep it at that mismatch and ignore it or try to solve it somehow
12:48:20 <prometheanfire> dirk: last summit the consensus was that UC was what we should use
12:48:23 <dirk> I would suggest to try to solve it
12:48:36 <tonyb> dirk: huh, I'm not sure about that
12:49:24 * dirk has to step out for a minute, brb
12:49:43 <tonyb> prometheanfire: what did you come up with positional?
12:50:38 <prometheanfire> as long as the projects that NEED a newer version have updated their requirements.txt packagers should be fine
12:51:14 <tonyb> prometheanfire: but they can't
12:51:25 <tonyb> prometheanfire: because it wouldn't pass the gate
12:51:28 <prometheanfire> well, then there's a problem
12:51:42 <tonyb> prometheanfire: that's what g-r is for
12:51:52 <prometheanfire> so then it needs to be bumped
12:52:46 <tonyb> prometheanfire: I agree that what we have is sub-optimal but bumping it would have a big impact on releases
12:52:47 <prometheanfire> doing the right thing can be hard :D
12:52:52 * dirk back
12:52:55 <tonyb> prometheanfire: it's only tests that are broken
12:53:21 <tonyb> IIUC
12:53:23 <prometheanfire> if it's only tests that's better, though we support running tests before install
12:53:39 <prometheanfire> we can restrict="tests" it though
12:53:49 <tonyb> prometheanfire: and if you have packaged 1.1.1 from u-c you wont see a problem
12:54:01 <prometheanfire> I think we should talk to the release team about the impact
12:54:30 <tonyb> prometheanfire: when there is a FFE email we can bring it up with dhellmann/ttx/dims
12:54:57 <prometheanfire> tonyb: the problem is, if packagers already have 1.0.1 packaged and it meets the requirements (gr being min version and uc being cap) then why do the extra work to bump?
12:55:00 <tonyb> prometheanfire: that's what the FFE is for to decide if the process impact if worth the tech debt
12:55:16 <toabctl> tonyb, I guess the people who do releases (like os-vif) don't even know that they need an FFE and I guess they also don't know that the new release is not tested.
12:55:49 <dirk> so should we as a requirements group just come up with the list of FFEs instead?
12:56:04 <tonyb> toabctl: that could be true, but I know that when I'm spnning on a release I pay a lot of attention
12:56:11 <prometheanfire> dirk: I'm starting to think so
12:56:40 <dirk> if we agree on that and it just requires a volunteer then let me know ;)
12:56:40 <tonyb> So I have 2 views 1) there is nothign stopping y'all doing that thing
12:56:51 * prometheanfire wants to send a ffe for positional
12:56:59 <tonyb> nothign says who has to raise the FFE, just that we need one to facilitate discusson
12:57:08 <prometheanfire> k
12:57:23 <toabctl> well - *I* can't say *why* os-vif is really needed. I can just copy the git commit messages in the FFE.
12:57:34 <toabctl> and for that we can have a bot :)
12:58:06 <dirk> toabctl: hopefully that was already discussed at the time when the release was made post freeze
12:58:14 <tonyb> toabctl: We'll you could jump on #openstack-nova ask ask the os-vif cores for help
12:58:18 <dirk> so we might just take a look at the discussion of the PR at releases repo
12:58:54 <zhiyuan> exit
12:58:55 <zhiyuan> exit
12:59:02 <tonyb> I can say that a poorly thought out FFE puts lots of work on PTLs
12:59:09 <dirk> tonyb: https://review.openstack.org/#/c/365104/
12:59:17 <tonyb> for instance I lost a day to the oslosphinx one
12:59:17 <dirk> tonyb: it actually says "point of the release is to fix some gating issue"
12:59:23 <dirk> which basically means we should merge the uc change
12:59:28 <prometheanfire> tonyb: endmeeting?
12:59:37 <tonyb> #endmeeting