[openstack-dev] [all][tc] establishing project-wide goals
flavio at redhat.com
Wed Aug 3 08:55:52 UTC 2016
On 02/08/16 17:29 +0200, Thierry Carrez wrote:
>Doug Hellmann wrote:
>>> Likewise, what if the Manila project team decides they aren't interested
>>> in supporting Python 3.5 or a particular greenlet library du jour that
>>> has been mandated upon them? Is the only filesystem-as-a-service project
>>> going to be booted from the tent?
>> I hardly think "move off of the EOL-ed version of our language" and
>> "use a library du jour" are in the same class. All of the topics
>> discussed so far are either focused on eliminating technical debt
>> that project teams have not prioritized consistently or adding
>> features that, again for consistency, are deemed important by the
>> overall community (API microversioning falls in that category,
>> though that's an example and not in any way an approved goal right
>Right, the proposal is pretty clearly about setting a number of
>reasonable, small goals for a release cycle that would be awesome to
>collectively reach. Not really invasive top-down design mandates that we
>would expect teams to want to resist.
>IMHO if a team has a good reason for not wanting or not being able to
>fulfill a common goal that's fine -- it just needs to get documented and
>should not result in itself in getting kicked out from anything. If a
>team regularly skips on common goals (and/or misses releases, and/or
>doesn't fix security issues) that's a general sign that it's not really
>behaving like an OpenStack project and then a case could be opened for
>removal, but there is nothing new here.
I think some flexibility on this should be considered (as mentioned by Thierry
in the previous paragraph) but I'd be quite worried of extremely special-cased
projects and I'd like us to be able to act on this cases.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 847 bytes
Desc: not available
More information about the OpenStack-dev