On 06/21/2016 12:53 PM, Doug Wiegley wrote:
On Jun 21, 2016, at 2:56 AM, Thierry Carrez <thie...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
