[openstack-dev] Policy around Requirements Adds (was: New class of requirements for Stackforge projects)
Mark McLoughlin
markmc at redhat.com
Tue Jul 8 08:33:13 UTC 2014
On Mon, 2014-07-07 at 16:46 -0400, Sean Dague wrote:
> This thread was unfortunately hidden under a project specific tag (I
> have thus stripped all the tags).
>
> The crux of the argument here is the following:
>
> Is a stackforge project project able to propose additions to
> global-requirements.txt that aren't used by any projects in OpenStack.
>
> I believe the answer is firmly *no*.
>
> global-requirements.txt provides a way for us to have a single point of
> vetting for requirements for OpenStack. It lets us assess licensing,
> maturity, current state of packaging, python3 support, all in one place.
> And it lets us enforce that integration of OpenStack projects all run
> under a well understood set of requirements.
Allowing Stackforge projects use this as their base set of dependencies,
while still taking additional dependencies makes sense to me. I don't
really understand this GTFO stance.
Solum wants to depend on mistralclient - that seems like a perfectly
reasonable thing to want to do. And they also appear to not want to
stray any further from the base set of dependencies shared by OpenStack
projects - that also seems like a good thing.
Now, perhaps the mechanics are tricky, and perhaps we don't want to
enable Stackforge projects do stuff like pin to a different version of
SQLalchemy, and perhaps this proposal isn't the ideal solution, and
perhaps infra/others don't want to spend a lot of energy on something
specifically for Stackforge projects ... but I don't see something
fundamentally wrong with what they want to do.
Mark.
More information about the OpenStack-dev
mailing list