Open Stack

David Kranz wrote:
> Going forward, and this may be controversial, I think these kinds of
> issues would be best addressed by following these measures:
> 
> 1. Require each blueprint that involves an API change or significant
> operational incompatibility to include a significant justification of
>     why it is necessary, what the impact would be, and a plan for
> deprecation/migration. This justification should assume that the remedy
>     will have to be applied to a large, running OpenStack system in its
> many possible variations, without having to shut down the system
>    for some unknown amount of time.

That would be useful. Strengthening a bit the feature proposal process
definitely can't hurt.

> 2. Require such blueprints to be approved by a technical committee that
> includes a significant representation of users/operators. The tradeoffs can
> be difficult and need to be discussed.

The Foundation bylaws propose that a "User committee" be set up. I hope
that the User committee can be quickly set up, gets respected people on
it and manages to be representative of all the users/operators of
OpenStack. If done properly, such a committee can get very influential
and its public "recommendations" cannot be easily ignored by the
developer side (the "technical committee").

> 3. The technical committee should declare that the bar for incompatible
> changes is high, and getting higher.
> 
> Some might argue that this is too much of a burden and takes authority
> away from PTLs, but I think the statement of stability to the
> community (and others) would more than compensate for that.

Using the "user committee" setup, you don't really need to take
authority away from the PTL. You increase the influence of the "users"
on technical decisions. You just provide a clear and official mechanism
to represent the interests of "the users" as a whole. Once you have
that, if the PTL or technical committee decides to ignore it, it's a
rather strong decision that better has to be well justified. Its better
than having some arbitrary percentage of "users" in a single committee
and then have most decisions won by the most largely represented party.

If the user committee is an active and respected group, it provides nice
checks and balances against developers living in developer bubbles. Most
issues we have right now with deployer-friendliness are linked to the
fact that "the users" don't have a clear or official voice.

The trick is, of course, to manage to set up such a committee in a way
that represents all the users and deployers. It will be all the more
influential if it is seen as representing all the users, rather than
just a loosely-tied pre-determined subset of large users.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack