Open Stack

On Fri, Oct 3, 2014 at 6:25 AM, Anne Gentle <anne at openstack.org> wrote:
>
>
> On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann <doug at doughellmann.com> wrote:
>>
>>
>> On Oct 3, 2014, at 12:46 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>>
>>
>> On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen
>> <devananda.vdv at gmail.com> wrote:
>>>
>>> On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann <doug at doughellmann.com>
>>> wrote:
>>> > As promised at this week’s TC meeting, I have applied the various blog
>>> > posts and mailing list threads related to changing our governance model to a
>>> > series of patches against the openstack/governance repository [1].
>>> >
>>> > I have tried to include all of the inputs, as well as my own opinions,
>>> > and look at how each proposal needs to be reflected in our current policies
>>> > so we do not drop commitments we want to retain along with the processes we
>>> > are shedding [2].
>>> >
>>> > I am sure we need more discussion, so I have staged the changes as a
>>> > series rather than one big patch. Please consider the patches together when
>>> > commenting. There are many related changes, and some incremental steps won’t
>>> > make sense without the changes that come after (hey, just like code!).
>>> >
>>> > Doug
>>> >
>>> > [1]
>>> > https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z
>>> > [2] https://etherpad.openstack.org/p/big-tent-notes
>>>
>>> I've summed up a lot of my current thinking on this etherpad as well
>>> (I should really blog, but hey ...)
>>>
>>> https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy
>>>
>>
>> After seeing Jay's idea of making a yaml file modeling things and talking
>> to devananda about this I went ahead and tried to graph the relationships
>> out.
>>
>> repo: https://github.com/jogo/graphing-openstack
>> preliminary YAML file:
>> https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml
>> sample graph: http://i.imgur.com/LwlkE73.png
>>
>> It turns out its really hard to figure out what the relationships are
>> without digging deep into the code for each project, so I am sure I got a
>> few things wrong (along with missing a lot of projects).
>>
>>
>> The relationships are very important for setting up an optimal gate
>> structure. I’m less convinced they are important for setting up the
>> governance structure, and I do not think we want a specific gate
>> configuration embedded in the governance structure at all. That’s why I’ve
>> tried to describe general relationships (“optional inter-project
>> dependences” vs. “strict co-dependent project groups” [1]) up until the very
>> last patch in the series [2], which redefines the integrated release in
>> terms of those other relationships and a base set of projects.
>>
>
> I'm reading and reading and reading and my thoughts keep returning to,
> "we're optimizing only for dev." :)
>
> I need to either get over that or decide what parts need tweaking for docs
> and support optimization. I'll get going on reviews -- thanks a bunch for
> all this compilation and for the good blog writing. Much appreciated.
>

Actually, while it looks like we're optimizing for dev, I'm not sure
that's actually what we're doing. But also, the patches Doug proposed
didn't capture several things I'm thinking about, so it's possible no
one else knows that yet. I've commented in gerrit, but I'll try to
also clarify it a bit here.

==========
(copying some comments from https://review.openstack.org/#/c/125787/2 )

I expressly do NOT want official project/team status to in any way
indicate that the horizontal teams (docs, qa, etc) suddenly need to
start supporting those projects. That will not scale, as we're already
seeing.

I believe we need to "let in" lots of code and lots of teams of people
who produce such code into the big tent of OpenStack, without
burgeoning the Integrated Release by cogating all of that, or
requiring the horizontal-scaling-efforts (docs, qa, etc) to take
responsibility for them, and also without indicating (whether
explicitly or implicitly) that those teams are The One True Way within
our community to do the thing they do.

==========

How does this relate to the gate structure changes that Monty and I
came up with two days ago?

When a change in one project breaks another project, because of poorly
defined API contracts, non-documented expected behaviors, and so on,
which we see all the time today, it's because we (developers) are
hitting some of the same problems that our users would hit when they
use these services. Right now, we're co-gating everything, so we are
able to gloss over these problems (to a degree, but not entirely). It
will be somewhat painful when we stop doing that. Projects will land
changes that break other projects' gates, which is not OK, and we'll
realize where a lot of unintended / undocumented inter-dependencies
are, and we'll have to make stable APIs around that. I think this is
actually very closely in line with what Jay's been proposing as well
(though I'm not yet sold on the "tags" part).

-Deva