On 23/04/15 12:14, Chris Dent wrote:
This might be a bit presumptuous, but why not give it a try...
Not at all, we should *strongly* encourage people to ask questions of
the candidates.
In fact, I think we should encourage everyone to contribute to the
discussion, not just the candidates.
This cycle's TC elections didn't come with a set of prepackaged
questions and though the self-nomination messages have included some
very interesting stuff I think it would be useful to get answers
from the candidates on at least one topical but open-ended
question. Maybe other people have additional questions they think
are important but this one is the one that matters to me and also
captures the role that I wish the TC filled more strongly. Here's
the preamble:
There are lots of different ways to categorize the various
stakeholders in the OpenStack community, no list is complete. For
the sake of this question the people I'm concerned with are the
developers, end-users and operators of OpenStack: the individuals
who are actively involved with it on a daily basis. I'm intentionally
leaving out things like "the downstream".
There are many different ways to define "quality". For the sake of
this question feel free to use whatever definition you like but take
it as given that "quality" needs to be improved.
Here's the question:
What can and should the TC at large, and you specifically, do to ensure
quality improves for the developers, end-users and operators of
OpenStack as a full system, both as a project being developed and a
product being used?
As you've identified, that is an extremely broad question and therefore
it can only be correctly answered with an extremely vague response ;)
The only known way to improve 'quality' for all definitions of 'quality'
is to make feedback loops shorter.
As for what the Technical Committee can do specifically, in the short
term I think the most important thing is to make sure that projects have
the flexibility to respond to their own individual challenges. I think
we've made some progress in this direction - for example, the
reorganisation that Neutron has been/is going through would probably
have been easier had it begun in a big-tent world (it's much easier to
split repos up than to punt parts of your project to stackforge), and
that's the kind of change that could potentially allow projects to bring
in more (but more specialised) core reviewers to reduce average
time-to-review, thus shortening an important feedback loop. So I think
the TC needs to be vigilant to make sure it's not making those kinds of
changes difficult.
And of course we should try to identify ideas that work and introduce
them to other projects who might benefit from them. But I don't think
that needs to be the TC's responsibility alone - anyone in the community
should feel able to do that. When I was a PTL I regarded my most
important responsibility to be making sure that everyone on the team saw
themselves as leaders of the project. I think the same applies to the TC.
[Warning: hand-waving ahead]
In the much longer term, I think the biggest improvement in quality
would come from finding a way to not solve the same problems multiple
times. I'll give an example: RabbitMQ doesn't scale. I hope that's not a
controversial example, I think it's generally agreed that it just
doesn't. Nova has developed Cells to enable itself to scale to very
large deployments despite that limitation (and others). As a result of
Cells being developed, every other project that uses RabbitMQ is...
exactly where it was before. That seems suboptimal.
Right now we have a lot of back-end interfaces where the semantics are
unclear to OpenStack developers, since they're deployer-defined in many
cases and no one project really owns them. (Example: even if
oslo-messaging didn't explicitly rule out durability by acknowledging
messages *before* they're delivered to the application, there's still no
way we could rely on it because who knows in what configuration RabbitMQ
is deployed?) Even worse, the interfaces don't support the invariants we
care about - like being able to scale to both extremely large and
extremely small deployments - so that every project must find a way to
reinvent those itself (or not), on top of the aforementioned unclear
semantics. I can't say how much impact this has on quality. I would
guess that it is both substantial and negative.
More co-operation between the various different deployment projects
might help a little, and in any event would be a Good Thing, and we
could start encouraging that right away.
Solving the problem entirely will be much harder, to put it mildly. I
don't know if we'll ever get there (though I don't think it's
impossible). I do believe that the first step is to have a conversation
about what our vision is for the OpenStack project as a whole, and I
think it will be much harder to have that conversation and follow
through on it if the TC is not committed to it.
cheers,
Zane.
__________________________________________________________________________
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
