[openstack-dev] Policy around Requirements Adds
Sean Dague
sean at dague.net
Tue Jul 8 10:26:51 UTC 2014
On 07/08/2014 04:33 AM, Mark McLoughlin wrote:
> 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.
Once it's in global requirements, any OpenStack project can include it
in their requirements. Modifying that file for only stackforge projects
is what I'm against.
If the solum team would like to write up a partial sync mechanism,
that's fine. It just needs to not be impacting the enforcement mechanism
we actually need for OpenStack projects.
-Sean
--
Sean Dague
http://dague.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140708/c283817e/attachment.pgp>
More information about the OpenStack-dev
mailing list