[openstack-dev] [all][tc] Equal Chances for all projects (was Plugins for all)

Hayes, Graham graham.hayes at hpe.com
Tue Jul 26 13:48:35 UTC 2016


On 26/07/2016 14:15, Sean Dague wrote:
> On 07/26/2016 08:51 AM, Doug Hellmann wrote:
> <snip>
>>
>> Given the amount of in-progress work to address the issue you've
>> raised, I'm not convinced we need a global rule or policy. All of
>> the teams mentioned are working toward the goal of providing stable
>> APIs already, and no one seems to be arguing against that goal. The
>> teams doing the work are not dragging their feet, and a rule or
>> policy wouldn't make the work go any faster.
>>
>> The directions for cross-project teams were given when the bit tent
>> change went into effect were to "support all official teams" and
>> definitely not "do the work for all official teams." There was also
>> no requirement that the support be exactly equal, and it would be
>> a mistake to try to require that because the issue is almost always
>> lack of resources and not lack of desire.  Volunteers to contribute
>> to the work that's needed will do more to help than a one-size-fits-all
>> policy.
>
> Yes, exactly.
>
> Like Ihar said earlier, we get all kinds of breaks across out system all
> the time. It's a complex system. If you look hard what you'll notice is
> that project interactions where there are team members in common break a
> bit less. For instance Grenade breaks Nova less than other projects.
> oslo.versionedobjects breaks Nova less than oslo.messaging does. Why?
> Because even with stable interfaces and tests, a lot of behavior remains
> in flux given the patch rate on all projects. And when people understand
> both sides of a problem, they are more likely to anticipate a problem
> during review that no tests caught and didn't seem to change an interface.
>
> This isn't a thing that gets fixed with policy. It gets fixed with people.
>
> 	-Sean
>

If this is where all these projects are going, is a policy not a good
way to indicate that this is how we want to work in the future?

So when the next project starts, or a team wants to move in a different
direction we have a piece of policy that shows we feel that this is the
way we work as a community?

I don't understand the objection to stating "this is how we should work"
when teams are moving that way anyway.

If to do that we need to dilute the policy, so be it.



More information about the OpenStack-dev mailing list