Open Stack

On 26/07/2016 18:47, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-07-26 13:48:35 +0000:
>> 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.
>>
>
> I do agree that writing down our expectations is a good thing.  In
> this case, I think the policy that the TC has agreed to is accurately
> and sufficiently documented in the existing resolution under the
> "Impact for horizontal teams" section [1].  The stewardship working
> group is actively working on a set of general principles for the
> TC to consider, and it may make sense to incorporate the existing
> policy into that list of principles to make it easier to find.

Sure, I know the work they are doing - this has been bouncing around
my PC for a bit before I had any knowledge of what the plans were there.

> I personally don't agree with changing the policy, or making it
> "stronger" in some way, right now because I'm not convinced that
> we need to treat all projects exactly the same in all cases.  It

This is the crux of the debate.

Are all projects equal?

If they are not, I will be disappointed, but we should then move to
define this in-equality, and state who is in, and who is out.

In some ways we are back to the stackforge vs integrated situation,
but unlike then we have no frame of reference for how a project would
become more equal.

If projects have difficulty getting into top level docs (for example)
it is more difficult to grow adoption, which would let them into
top level docs, which would help adoption ...

> seems like a relatively benign assumption to make, but until we
> actually have an issue that would be solved by formalizing it in

I think that we have one. I could be wrong (it happens), but I think
this is a problem, and waiting for something bigger to happen, then
having the existential debate about what OpenStack is (again) causes
issues that could be dealt with to grow. (See Golang discussion).

> policy I would prefer to avoid introducing unintended consequences
> in implementations of projects brought on by layers of rules.  We
> don't want any projects discriminated against, but I don't think
> that's what is happening in these cases, and I think the existing
> policy addresses that case.

And I disagree - I think we need it to be more explicit.

> Doug
>
> [1] http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html#impact-for-horizontal-teams
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>