Open Stack

On 06/21/2016 12:53 PM, Doug Wiegley wrote:
>> On Jun 21, 2016, at 2:56 AM, Thierry Carrez <thierry at openstack.org>
>> wrote:
>> Chris Dent wrote:
>>> On Mon, 20 Jun 2016, Doug Wiegley wrote:
>>>> So, it sounds like you’ve just described the job of the TC. And
>>>> they have so far refused to define OpenStack, leading to a
>>>> series of derivative decisions that seem … inconsistent over
>>>> time.
>>>
>>> Thanks for writing down what I was thinking. I agree that
>>> OpenStack needs some architectural vision, direction, leadership,
>>> call it what you will. Every time I've voted for the _Technical_
>>> Committee that leadership is what I've wanted my vote to be
>>> creating.
>>
>> The TC is a representative body which is elected to make top-down
>> decisions on OpenStack. However, as much as our community loves the
>> idea of "technical leadership" and "vision", they hate the top-down
>> decisions that come with it (especially when that top-down decision
>> doesn't go their way). They prefer bottom-up consensus.
>>
>> So I'd argue that you need both. You need the TC whenever a hard
>> call has to be made, but in order to minimize the number of those
>> hard calls (and favor consensus building) you also need working
>> groups to build a bottom-up reasonable way forward.
>
> This reads very strange to me, as I’d expect a group of technical
> leaders to both make hard calls *and* to be able to build consensus
> on overall direction and vision. They’re two sides of the same coin.
> What is it about our process that means the TC can’t build consensus
> on direction, but can only impose its will? I expect you didn’t mean
> it to sound that way, though. Is the workload too high on the
> bookkeeping to prevent the vision building? Are we too afraid of the
> implications of defining ‘what is openstack?’, and what it might mean
> to existing projects and the community? I’d think that in the
> long-run, it’d prevent seemingly unrelated topics from seeming to go
> sideways so often, and prevent a lot of these “hard calls”.

Perhaps you weren't around for the endless (and pointless) discussions 
around what is "the core of OpenStack"? Or you weren't around for the 
endless (and conflicting, contradictory, and religious) battles that 
were waged during the old "incubation" and "graduation" procedures?

Ask Clint, Flavio and Devananda how fruitful the Marconi/Zaqar 
"architectural review" by the TC was.

> But, I’m also on the fringe that is very ready to call the “big tent”
> a failed experiment in attempting to avoid hard calls, too.

That's because you think the big tent initiative is something that it is 
not.

And we've had this conversation before, but you insist on equating the 
big tent initiative with the TC broadening what its definition of 
OpenStack was. And that's not what the big tent initiative was, as I've 
said repeatedly.

The big tent initiative was specifically to change from a subjective set 
of requirements that a project must meet in order to be "part of 
OpenStack" into an objective set of requirements.

We removed the subjective, bike-shedding, and cringe-inducing 
"graduation review" from the application process and instead focused on 
documenting a clear set of objective requirements that projects could 
obligate themselves to meeting if they wanted to "be part of OpenStack".

>>> It may be that an architecture working group can provide some
>>> guidance that people will find useful. Against the odds I think
>>> those of us in the API-WG have actually managed to have a
>>> positive influence. We've not shaken things down to the
>>> foundations from which a great a glorious future may be born -- a
>>> lot of compromises have been made and not everybody wants to play
>>> along -- but things are going in the right direction, for some
>>> people, in some projects. Maybe a similar thing can happen with
>>> architecture.
>>
>> That is my hope. I see the API WG and the Architecture WG as groups
>> of experts in specific domains preparing recommendations and
>> long-term plans. They don't have authority to force them onto
>> projects. Ideally projects adopt them because they see them as the
>> right way to do things.
>>
>> And for the very few things that the TC deems necessary for
>> OpenStack and where bottom-up didn't get it in a specific project
>> (if all else fails), the TC can make a top-down request to a
>> project to do things a certain way. The project can them either
>> comply or reject the TC oversight and become an unofficial
>> project.
>
> Don’t get me wrong, I welcome this initiative. I find it mildly
> disconcerting that the folks that I thought we were electing to fill
> this role will instead be filled by others, but the vacuum does need
> to be filled, and I thank Clint for stepping up.

I don't particularly think it's a vacuum that can be filled by a small 
group of "architects". My experience is that unless said architects are 
actually involved in building the software at hand and have a good 
understanding of why certain design choices were originally made in the 
various projects, the end deliverable of such a group tends to be the 
software equivalent of silly putty -- fun to play with but in the end, 
relatively free of practical value.

Best,
-jay