[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