12:00:44 <tonyb> #startmeeting requirements
12:00:45 <openstack> Meeting started Wed Aug 10 12:00:44 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:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:48 <openstack> The meeting name has been set to 'requirements'
12:00:57 <tonyb> #topic rollcall
12:01:04 <coolsvap> o/
12:01:18 <prometheanfire> o/
12:01:35 <toabctl> hi
12:02:17 <tonyb> dirk: was around earlier ....
12:02:28 <dirk> o/
12:02:33 <dhellmann> o/
12:02:37 <dirk> I'm here :)
12:03:02 <tonyb> hey dhellmann.  Nice to see you.
12:03:15 <dhellmann> hi, tonyb, sorry for not making it to more of these
12:03:42 <tonyb> dhellmann: it's all good, timing is hard with US/Europe and Australia
12:04:02 <tonyb> #topic Any controversies in the Queue?
12:04:26 <tonyb> so the queue is teeny right now so I don't think there's anything terrible in there
12:04:58 <prometheanfire> neutron things, do we wait like we did with horizon things?
12:05:20 <prometheanfire> I tried asking in -neutron to no response
12:05:43 <prometheanfire> also, http://logs.openstack.org/6c/6c3b4315443e2963ffbba9d1030c6e5dffe2514e/post/propose-requirements-updates/f4c6ca9/console.html#_2016-08-08_11_38_31_730575
12:05:44 * dhellmann is about to process the oslo releases for the week
12:05:58 <prometheanfire> some projects aren't getting updates
12:06:15 <tonyb> prometheanfire: I have names to add, armax, otherwiseguy and yamamoto
12:06:18 <prometheanfire> I've worked with two of them, others are non-responsive in irc, going to have to submit bugs
12:06:31 <tonyb> dhellmann: \o/
12:06:58 <tonyb> dhellmann: The new testing makes them a litle more fun than they were :)
12:07:50 <dhellmann> tonyb : which (or how many) extra projects are being tested now?
12:08:05 <sigmavirus> dhellmann: probably not enough :P
12:08:28 <tonyb> dhellmann: about 6 defcore + neutron and horizon
12:08:36 <tonyb> dhellmann: covers 54% of g-r
12:08:41 <dhellmann> tonyb : nice
12:08:46 <tonyb> dhellmann: it isn't perfect but it's a start :)
12:08:55 <dhellmann> sigmavirus : that's an excellent improvement, even if it's incomplete
12:09:13 <sigmavirus> dhellmann: I completely agree. Hence the ":P"
12:09:56 <tonyb> dhellmann, sigmavirus: it's aleas going to be a balance between covereage and not killing the gate :(
12:10:08 <dhellmann> tonyb : right
12:10:20 <tonyb> prometheanfire: Hmm tracking those failures will be fun :(
12:10:29 <prometheanfire> tonyb: I've been working on that
12:10:31 <sigmavirus> tonyb: I agree :)
12:10:36 <prometheanfire> monasca and freezer are fixed
12:10:37 <tonyb> prometheanfire: cool.
12:10:49 <tonyb> prometheanfire: double cool
12:11:00 <prometheanfire> 2 or 3 to go
12:12:39 <tonyb> So we'll have a rush on olso u-c bumps after dhellmann does his thing, we have a few post update failure to track and we need neutron to at least look at the ovs/ryu updates
12:12:51 <prometheanfire> ya, he's doing it now :P
12:12:57 <tonyb> sound like a fair summary of the review queue?
12:13:00 <prometheanfire> ya
12:13:04 <tonyb> :)
12:13:15 <tonyb> moving on?
12:13:40 <prometheanfire> y
12:13:42 <prometheanfire> es
12:13:48 <tonyb> #topic Additional Gating - Updates
12:14:08 <tonyb> I left this in as there was a discussion we cut short last week
12:14:42 <tonyb> coolsvap: had an action out of that but he's wounded so probably isn't up to typing about that tonight
12:14:53 <tonyb> coolsvap: does that sound reasonable?
12:15:16 <coolsvap> tonyb: yes
12:15:31 <coolsvap> I will create an etherpad
12:15:37 <prometheanfire> k
12:15:42 <tonyb> coolsvap: okay.  No rush
12:16:21 <tonyb> skiiping over the setuptools discussion item as it was supposed to be removed from the agenda ... my bad
12:16:33 <tonyb> #topic Approval rules for requirements
12:17:16 <tonyb> So this was me ... I wanted to level set on what we "fast" approve and what we do the more typical 2*+2+W
12:17:35 <tonyb> I started a thread on os-dev which went a little wonky but
12:17:55 <prometheanfire> that's normal
12:18:12 <tonyb> it seem that there is an established pattern in the README, are we happy with that?
12:18:45 <prometheanfire> I think we should probably switch to 2*+2+W for gr updates at least
12:18:54 <prometheanfire> UC updates should probably stay at 1
12:19:04 <prometheanfire> only because we don't have that many active cores
12:19:11 <prometheanfire> but I'd be fine with 2 there as well
12:20:19 <tonyb> dirk?
12:20:19 <dhellmann> it's currently 1 * +2+w for lower bounds updates of things we manage, right?
12:20:33 <tonyb> dhellmann: Yes
12:20:52 <dhellmann> and what's the motivation for changing that?
12:21:02 <prometheanfire> dhellmann: UC and GR both have that same rule
12:21:47 <tonyb> dhellmann: I was a little shocked that it was there and wanted to understand why it was there
12:21:52 <coolsvap> I want 2*2+W for all requirement reviews unless explicit urgent requirement
12:21:59 <tonyb> dhellmann: it could be that my world view is wrong
12:22:39 <dhellmann> I think we said we wanted more careful consideration of adding new things, but managing what we already have on the list should be lightweight
12:22:43 <tonyb> dhellmann: I given the way g-r updates propogate a mistake there is harder to back out
12:23:11 <dhellmann> some of that may have come at a time when we had so few folks participating in reviews that it was necessary, and that may no longer be the case
12:23:21 <dhellmann> so I'm not arguing against a change, just asking to understand the proposal
12:23:56 <dhellmann> now that we have a really active team managing the list, asking for 2 reviews won't mean having a change blocked
12:23:57 <tonyb> dhellmann: right now I don't think there is a *strong* proposal.  most of us are new to this ;P
12:24:39 <dhellmann> but like I said on the ML, the main point of raising minimums is when a project wants to ensure a new feature of a library is there, and that happens fairly often for oslo libs (or it did at one point) so making that process smooth and quick was deemed important
12:25:01 <dhellmann> again, though, this is all history and definitely open for revision
12:25:34 <tonyb> dhellmann, coolsvap: I see our role as facilitatators and I don't wnat to create slowdowns or bottle nexk for projects but we also need to balance the risk.
12:26:08 <dhellmann> I completely agree with that
12:26:16 <coolsvap> tonyb: agreed
12:26:19 <prometheanfire> so
12:26:29 <tonyb> dhellmann: I suspected some of the fast approvals may have been due to reviewer bandwidth so you've at least indicated that that may have been the case.
12:26:38 <prometheanfire> switch to 2*+2 for all or at least gr
12:26:46 <coolsvap> my only point is we need to balance facilitation and risk
12:27:07 <tonyb> coolsvap: yup.
12:27:09 <coolsvap> we can always expedite
12:27:29 <coolsvap> but we should not unless explicitly required
12:28:02 <tonyb> *or* we could leave it as it is and establish a process for "this scares me don
12:28:07 <tonyb> 't fast path it
12:28:17 <coolsvap> if we have 2*2+W throughout
12:28:19 <tonyb> which is probably just a -2 with a similar message
12:28:35 <tonyb> if it's expected then it's less of a schock
12:28:46 <prometheanfire> ya, for those it's mostly about ryu/ovs type stuff right now
12:29:24 <coolsvap> i am not big fan of -2s
12:29:50 <tonyb> prometheanfire: and a little we know $fu is broken but not enough to black list it so don't take the bot u-c update
12:29:50 <coolsvap> -1 from any core should be sufficient to acknowledge stop approve
12:30:10 <prometheanfire> ya
12:30:32 <prometheanfire> coolsvap: ya, -2 in this case shouldn't ne needed
12:31:22 <tonyb> I'm on the fence there.  -2's used appropriately are a tool
12:31:40 <tonyb> they have a stigma but that's not totally deserved
12:31:45 <tonyb> my $0.02
12:31:57 * sigmavirus agrees with tonyb
12:32:02 <prometheanfire> true, but -2 needs to wait for removal
12:32:02 <tonyb> if a core's -1 == -2 then why have a -1?
12:32:13 <prometheanfire> that's the only reason why
12:32:29 <dhellmann> I think as long as you clearly explain the policy/process to folks outside the team, either is fine.
12:32:36 <tonyb> prometheanfire: but that's a good thing IMO
12:32:40 <prometheanfire> so we are blocked on the -2 until the person who put it is removed
12:32:51 <sigmavirus> right, I feel like aversion to a -2 is because some cores will want to approve something against another core's opinion
12:32:59 <sigmavirus> That favors "speed" over consensus
12:33:01 <prometheanfire> it is a good thing, when there's a strong personal opinion or question needing answered
12:33:13 <prometheanfire> but since this is for 'team actions' I don't think it's good
12:33:20 <tonyb> dhellmann: I agree
12:34:07 <tonyb> prometheanfire: we have to trust cores wont -2 things without a good reason.
12:34:25 <prometheanfire> yes
12:34:41 <prometheanfire> I thought you were talking about doing it to all updates to certian packages
12:34:51 <prometheanfire> emphasis on the _all_
12:35:46 <tonyb> prometheanfire: no Just the ones that nees extreem care (like I did with the oslo.context stuff)
12:36:00 <prometheanfire> ya
12:36:05 <prometheanfire> that's good use :D
12:36:21 <prometheanfire> so I think we agree then (not sure about coolsvap's opinion)
12:37:00 <coolsvap> I am fine with -2 jjust I am not big fan of it
12:37:16 <coolsvap> but do we agree on 2*+2+W ?
12:38:11 <prometheanfire> +1
12:38:21 <coolsvap> we similarly need to create policy for new packages
12:38:40 <prometheanfire> policy for new packages is 2*+2+W
12:38:41 <prometheanfire> iirc
12:38:50 <dhellmann> yes, that should be the policy already
12:38:58 <coolsvap> I think it needs to extended
12:39:22 <coolsvap> we need formal packagers review
12:39:22 <sigmavirus> so what I'm hearing is that coolsvap is going to put together a doc change for these policies and let voting happen there and announce it to the mailing list so people are aware of the policy changes we're talking about, right?
12:39:27 <tonyb> prometheanfire: I think coolsvap is suggesting that we wait for a positve review from a deb, rpm and gentoo packager for new things
12:39:43 <prometheanfire> oh
12:39:44 <prometheanfire> that
12:40:02 <sigmavirus> tonyb: prometheanfire coolsvap we could add an extra label that are given to packagers for the requirements project so that you can add them to a group and have them vote as packagers on a review
12:40:09 <sigmavirus> that may provoke them to participate more
12:40:22 <prometheanfire> that's true, about participation
12:40:49 <prometheanfire> I'm not sure packagers actually need to review (though it is nice), anyone can do a package search
12:40:57 <prometheanfire> each distro has a link to their 'search'
12:41:03 <prometheanfire> in the readme
12:41:18 <sigmavirus> is that really the only thing packagers contribute though?
12:41:28 <dhellmann> prometheanfire : could we automate that search?
12:41:31 <prometheanfire> and for gentoo, as long as UC is co-installable (which is debatable at times) the we are good
12:41:33 <tonyb> prometheanfire: right but I wouldn't feel comfortable saying $this_thing *can* be packaged for $disro
12:41:34 <sigmavirus> If it's that easy, why not automate it and make it part of CI
12:41:36 <sigmavirus> damnit dhellmann beat me
12:41:43 <prometheanfire> dhellmann: don't think so, mainly because names change
12:42:01 <tonyb> prometheanfire: and that's where I think packagers add value in the review
12:42:12 <dhellmann> could we do a best-effort automated search with links in the output when something can't be found?
12:42:14 <prometheanfire> tonyb: ya, if it's missing having them say something is a good thing
12:42:18 <prometheanfire> double+good
12:42:19 <coolsvap> and some packages are not part of the distro but can be packaged or cannot be packaged or duplicates
12:42:36 <dhellmann> sort of like how we have the list-changes job for releases, where it just dumps a bunch of info that makes it easier to look at what's in a release without doing it by hand yourself
12:43:02 <tonyb> dhellmann: that's an interesting idea
12:43:10 <prometheanfire> one thing we need to keep in mind while asking them is their response time
12:43:28 <dhellmann> I also don't think we want a policy of blocking new dependencies until they're packaged
12:43:51 <prometheanfire> exactly
12:43:53 <sigmavirus> dhellmann: right, so if we were to add a new vote label and give that to packagers, we could say "2 packagers need to approve this" before we approve the change
12:44:05 <coolsvap> no not blocking them until packaged
12:44:09 <prometheanfire> ya, a majority of packagers would be good
12:44:12 <dhellmann> we want to get input about something that's impossible to package, but we don't want to stall our community's work until distros say it's ok
12:44:19 <coolsvap> but having more views
12:44:20 <sigmavirus> Instead of saying "All packagers need to approve it" which I wasn't suggesting, but it seems people read "all" into a lot of things in this emeting
12:44:34 <sigmavirus> coolsvap: no one is suggesting blocking until packaged though
12:44:44 <sigmavirus> we just want some number of packagers to say "this looks good to us"
12:44:47 <prometheanfire> I can say from a gentoo perspective there's very little we will say no to...
12:44:59 <sigmavirus> this also means packagers don't need to be cores but they are their own team
12:45:00 <dhellmann> sigmavirus : ok, I misunderstood. Do we have enough active packaging folks involved to even say we'll wait for 2? I haven't been keeping up...
12:45:01 <tonyb> okay I think we need to wind this up we only have 15mins left
12:45:11 <sigmavirus> dhellmann: prometheanfire is one :P
12:45:17 <tonyb> dhellmann: Yeah we do
12:45:21 <sigmavirus> I think haikel was rather involved but I haven't been paying attention
12:45:24 <dhellmann> cool, that's good to hear
12:45:35 * sigmavirus probably misspelt their name :(
12:45:38 <prometheanfire> my vote is almost always yes though, not sure how useful it is (as a packager)
12:46:07 <sigmavirus> prometheanfire: it's a good counterbalance to the packagers whose vote is almost always no though =P
12:46:15 <prometheanfire> we had/have deb/fedora/suse/gentoo
12:46:16 <dhellmann> rather than making those folks separate, we could also explore getting them up to speed enough to be core
12:46:22 <prometheanfire> sigmavirus: lol
12:46:36 <tonyb> dhellmann: most of then are core
12:46:51 <dhellmann> ok, then I'm not sure I see the point of a separate vote label
12:46:52 <tonyb> dhellmann: so job done :)
12:46:52 <prometheanfire> we need an action item to enumerate who's our 'contact' to see if we can get a group for voting
12:47:09 <sigmavirus> dhellmann: I wasn't aware that most already were core
12:47:09 <tonyb> ok so in summary
12:47:18 <sigmavirus> so that's why I suggested the separate vote label :D
12:47:20 <dhellmann> sigmavirus : ok, cool
12:47:25 <prometheanfire> I'm not sure most are core, but enumerating them would be good
12:47:29 <sigmavirus> I was under the impression that few were core
12:47:38 <dhellmann> prometheanfire : +1 to writing things down
12:47:38 <sigmavirus> ¯\_(ツ)_/¯
12:47:41 <prometheanfire> a few were
12:47:51 <sigmavirus> right, so we need an action for coolsvap to write down the policy changes around votes
12:47:52 <tonyb> we need to do more thinking on the approval rules thing as we're only mostly on the same page
12:48:10 <sigmavirus> (because coolsvap seems to be the driver of that change)
12:48:46 <tonyb> sigmavirus: I'm not entirely certain that's a fair read.
12:49:00 <tonyb> sigmavirus: I opened this can of worms, but I don't have a proposal yet
12:49:31 <tonyb> #action Think more on approval rules befoer next meeting
12:49:59 <coolsvap> +1
12:50:06 <tonyb> #topic Tasks from Etherpad
12:50:08 <prometheanfire> and one for packager votes/figuring out our packager pool?
12:50:15 <tonyb> Interim PTL Election - Results available after 13:00 utc August 11, 2016.
12:50:19 <prometheanfire> those are two separate rule changes
12:50:25 <tonyb> #link http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_02dbd8750c568757
12:50:53 <tonyb> prometheanfire: sure.  2 seperate things but 1 related
12:51:02 <prometheanfire> ya
12:51:08 <tonyb> #link https://etherpad.openstack.org/p/requirements-tasks
12:51:42 <prometheanfire> I added a task
12:51:43 <prometheanfire> figure out _ vs - in the canonical names for django_openstack_auth, glance-store and ironic-lib (etc)
12:51:58 <tonyb> dhellmann: Do you consider the u-c updates for packages in non-canonical form resolved?
12:51:59 <prometheanfire> that was a request from dhellmann
12:52:08 <tonyb> dhellmann: now that you updated release.sh
12:52:39 <dhellmann> tonyb : it would be nice if we could standardize, but it turns out doing that introduces a whole host of other issues
12:52:42 <dhellmann> #link https://review.openstack.org/#/c/352929/
12:52:53 <dhellmann> so yeah, for now at least I think ^^ takes care of it
12:53:36 <tonyb> dhellmann: ok
12:53:46 <prometheanfire> dhellmann: if you could add info to line 53 (item 18) that'd be nice :D  https://etherpad.openstack.org/p/requirements-tasks
12:54:58 <tonyb> prometheanfire: I was just going to move it to "done"
12:55:43 <prometheanfire> that's fine too, if dhellmann is happy
12:55:49 <tonyb> dhellmann: Thanks.
12:56:31 <tonyb> Anything else in there we need to touch on ?
12:56:32 <prometheanfire> next/done?
12:56:41 <tonyb> I think we're close to closign a few
12:56:56 <tonyb> #topic Open Discussion
12:57:00 * dhellmann has to drop off
12:57:06 <dhellmann> prometheanfire : info added
12:57:09 <prometheanfire> thanks
12:57:38 <tonyb> number80 has optional-requirements stuff but has a cold ...
12:57:41 <tonyb> anythin else?
12:57:45 <tonyb> dhellmann: Thanks!
12:58:31 <tonyb> going once .....
12:59:02 <tonyb> going twice  .....
12:59:28 <tonyb> Thanks everyone
12:59:31 <tonyb> #endmeeting