20:28:43 <prometheanfire> #startmeeting requirements
20:28:44 <openstack> Meeting started Wed Aug  8 20:28:43 2018 UTC and is due to finish in 60 minutes.  The chair is prometheanfire. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:28:45 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:28:47 <openstack> The meeting name has been set to 'requirements'
20:28:54 <prometheanfire> #topic rollcall
20:28:57 <prometheanfire> tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann
20:28:57 <tonyb> o/
20:29:00 <prometheanfire> o/
20:29:34 <dhellmann> o/
20:30:17 <prometheanfire> ok, moving on
20:30:27 <prometheanfire> #topic controversies in the queue?
20:30:36 <prometheanfire> https://review.openstack.org/589405
20:30:44 <prometheanfire> #link https://review.openstack.org/589405
20:31:45 <prometheanfire> raising the min, especially on something like this is a pain since the infra sync was stopped for ALL branches
20:32:20 <tonyb> Yeah no we can't do that it doesn't make sense, if anythign they'll need to ad a compat shim
20:32:31 <prometheanfire> I'm not sure if it makes sense anyway
20:32:35 <tonyb> I agree to dhellmann, I doin't get why the u-c bump isn't adeqaute
20:32:38 <prometheanfire> ya
20:33:47 <prometheanfire> they did say that they'd stop reqs syncing if they didn't get this in, not that threats will be accepted, just funny
20:33:54 <prometheanfire> so, just comment in the review
20:35:26 <tonyb> Okay, well It's against our policy and it's one moer example where our policy causes problems, queesn is the last branch where that happens so I guess we'll try to educate and if they still don't like it that can disable the requierments-check job
20:35:48 <prometheanfire> ya
20:35:59 <prometheanfire> anyone have anything else?
20:36:13 <tonyb> not for controversies
20:36:28 <prometheanfire> tonyb: you're up
20:36:42 <tonyb> I'm on the fence about applying for FFE's for the cleanup I did, and we're blocked on the bindep stuff until we fix infra
20:37:08 <prometheanfire> tonyb: I just want a FFE for completeness, I'd approve it, just have to ask
20:37:09 <tonyb> ... So given we have per-project lower bounds now
20:37:50 <tonyb> what if anything stops a project from releasing rocky with foo>=1.0.0 and then during the cycle bumping that to >=1.1.0 ?
20:37:53 <prometheanfire> altering our FFE policy is probably going to be a big thing for the ptg
20:38:17 <dhellmann> tonyb : nothing
20:38:32 <prometheanfire> locking down lower-constraints/exclusions is not done, but does it need to be done?
20:38:41 <tonyb> currently we have an agreement with vendors that we wont bump minimums which we can do for <= queens
20:39:10 <dhellmann> we could modify the check job so that it enforces that rule on stable branches
20:39:17 <tonyb> I've asked vendors if havign that contact adds value and I never get a firm answer so perhaps I'm just being silly
20:39:26 <prometheanfire> dhellmann: I'd be happy with that
20:39:32 <dhellmann> although I suspect leaving it to the stable reviewers would be good enough
20:39:35 <tonyb> we've already said use u-c but that's hard for enterprise distros
20:39:43 <dhellmann> I hate adding hard blockers against something that might be needed
20:40:06 <tonyb> dhellmann: Yeah I agree.
20:40:22 <dhellmann> dependency changes are visible in the release review process, fwiw
20:40:37 <prometheanfire> it could still be overridden by stable I think
20:40:38 <tonyb> dhellmann: we do do it from timem to time so writing a tool/check and a bypass mechanism seems like we're doign somethign wrong
20:40:54 <tonyb> dhellmann: That is true
20:41:13 <dhellmann> prometheanfire : I'm not sure what you mean?
20:41:50 <prometheanfire> adding an exclusion for something should still be possible
20:42:08 <dhellmann> as long as it doesn't effectively raise the min, yeah
20:42:15 <prometheanfire> ya
20:42:23 <prometheanfire> we have to be carful there
20:42:24 <dhellmann> my point is that sometimes we do want to raise the min -- like if it was wrong to begin with
20:42:33 <tonyb> then we get >=1.0.0,!=1.0.0 ;P
20:42:53 <dhellmann> I would hate for us to paint ourselves into a corner where we don't let ourselves fix something that's actually broken
20:43:21 <prometheanfire> tonyb: ya, we've been over that before
20:43:25 <tonyb> I really don't want to push this onto the release team, nor do I like the idea of askign for revert's at release time
20:43:31 <dhellmann> we have a governance tag that indicates whether the deliverable follows the stable policy, so we have a way to block a release if there is a bad version update
20:43:49 <dhellmann> maybe we use the tag to control the check job?
20:44:02 <dhellmann> if on a stable branch and repo has the flag, do not allow the min to change
20:44:07 <tonyb> dhellmann: We could I suppose ...
20:44:32 <prometheanfire> and adding exclusions? same rule?
20:45:04 <dhellmann> no, I think it's ok to leave the exclusion management the same. we already require that to be a subset of what is in the global list so we have a review step there
20:45:29 * smcginnis tries to catch up on scrollback
20:47:35 <prometheanfire> so do we need an action item to create those job/rules?
20:48:05 <tonyb> okay so we *can* do somethign for stable/* and projects that have stable:follows-policy but *should* we?
20:48:23 <tonyb> prometheanfire: perhaps lets answer my question first ...
20:48:29 <prometheanfire> :P
20:48:50 <prometheanfire> tonyb: you were the one concerned about slow distros :P
20:49:00 <dhellmann> what is the risk of not doing it?
20:49:28 <tonyb> prometheanfire: Well more accurately I was concerned that of code chnages impleied a process chnage that we hadn't communicated
20:49:30 <prometheanfire> I think it's a valid concern and we should lock down min bumps for follows-policy repos
20:49:34 <smcginnis> We let l-c updates through and a distro isn't prepared to adjust to the higher constraint?
20:50:03 <tonyb> prometheanfire: I don't mind if we dicide that's a good thing and communicate it *or* if we add code to reimplement it
20:50:06 <prometheanfire> tonyb: it sounds like we are wishing to keep the status quo for released branches
20:50:07 <dhellmann> smcginnis : we tend to only update l-c on stable for our own releases
20:50:27 <dhellmann> I think i would rather wait and see if it's actually a problem.
20:50:34 <prometheanfire> it's good to re-communicate it, but it wouldn't be a change in the rules, just how they are enforced
20:50:43 <dhellmann> I don't feel like the risk to the community is that high
20:50:53 <smcginnis> It doesn't seem like it.
20:50:59 <dhellmann> and yes, we should communicate the policy
20:51:36 <dhellmann> smcginnis : sorry, I read l-c as u-c -- yes, we don't currently have any check blocking changes to the lower bounds or lower-constraints.txt
20:51:40 <dhellmann> except that they have to match
20:52:06 <dhellmann> this might make a good lunch topic at the ptg, fwiw
20:52:25 * dhellmann has to sign off
20:52:28 <tonyb> dhellmann: Perhaps ;P
20:52:30 <smcginnis> dhellmann: Yeah, that was trying to answer the question "what is the risk of not doing it?" I think the risk doesn't really exist.
20:52:35 <tonyb> dhellmann: Okay thanks for your time
20:52:44 <dhellmann> smcginnis : the risk is downstream of us
20:52:50 <prometheanfire> yep, tony is bringing it up now because stable branching is already happening
20:52:56 <dhellmann> if we start requiring a version of something not packaged in a distro
20:53:02 <tonyb> COrrect this is totally upstream trying to make downstream's life better
20:53:09 <prometheanfire> yarp
20:53:33 <dhellmann> I think it's a good idea both to communicate that we want teams not to change mins on stable branches and that we no longer have automation preventing that
20:53:42 <dhellmann> that way everyone knows the state of things
20:54:21 <prometheanfire> that's fine
20:54:33 <prometheanfire> next question is if we want enforcement of that policy
20:54:34 <tonyb> dhellmann: Cool I'll do that ... and I may ask the TC for some help trying to get vendors to actually answer when I ask if this helps or hurts them ;P
20:55:05 <prometheanfire> tonyb: that'd be nice (the answer from tc)
20:55:26 <prometheanfire> next?
20:55:27 <tonyb> prometheanfire: The TC isn't a problem it's vendors
20:55:38 <prometheanfire> tonyb: ya, not blaming them
20:55:46 * tonyb is done
20:56:46 <prometheanfire> ok, only other thing I see is the two other FFE requests to bump minimums for sphinx and  python-monascaclient
20:56:56 <prometheanfire> it's really late to be doing that
20:57:23 <tonyb> I'd have to read why but my gut is sphinx == no python-monascaclient == yes
20:57:31 <prometheanfire> sure
20:57:50 <prometheanfire> me too, I think they need to read the primer on per-project reqs
20:58:04 * prometheanfire will always call that divergent reqs in his head
20:58:40 <prometheanfire> because they may not need that everywhere, just in a repo or two
20:58:59 <tonyb> prometheanfire: Yup.
20:59:21 <prometheanfire> I have nothing else
20:59:28 <prometheanfire> #topic open floor
21:00:27 * tonyb is good
21:00:40 <prometheanfire> ya, will wait a min more
21:02:42 <smcginnis> Sorry, distractions. Nothing here.
21:02:57 <prometheanfire> #endmeeting