[openstack-dev] [all][tc] establishing project-wide goals

Jay Pipes jaypipes at gmail.com
Tue Aug 2 16:02:41 UTC 2016


On 08/02/2016 11:29 AM, 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
>> now).
>
> 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.

Sure, I have no disagreement with any of the above. I just see TC 
mandates as a slippery slope. I'm practicing my OpenStack civic "duty" 
to guard against the encroachment of project technical independence.

Best,
-jay



More information about the OpenStack-dev mailing list