Open Stack

On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) <
kevinbri at cisco.com> wrote:

> ATC is only being given to folks committing to the current branch (
> https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/
> ).



> Secondly, it's difficult to get stack-analytics credit for back ports, as
> the preferred method is to cherry pick the code, and that keeps the
> original author's name.
>


> My fear is that we're going in a direction where trunk is the sole focus
> and we're subsequently going to lose the support of the majority of the
> operators and enterprises at which point we'll be a fun research project,
> but little more.
>

[I've cherry-picked above what I think are the main points here... not
directed at you Kevin.]


This is not Somebody Else's Problem.

Stable maintenance is Not Much Fun, no question.  Those who have demanded
the loudest that we (the development community) maintain these stable
branches need to be the one supporting it the most. (I have no idea how
that matches up today, so I'm not pointing out anyone in particular.)

* ATC credit should be given, stable branch maintenance is a contribution
to the project, no question.

* I have a bit of a problem with stack-analytics being an issue partially
because that is not what should be driving corporate contributions and
resource allocation.  But it does.  Relying on a system with known
anomalies like the cherry-pick problem gets imperfect results.

* The vast majority of the OpenStack contributors are paid to do their work
by a (most likely) Foundation member company.  These companies choose how
to allocate their resources, some do quite well at scratching their
particular itches, some just make a lot of noise.  If fun is what drives
them to select where they apply resources, then they will reap what they
sow.

The voice of operators/users/deployers in this conversation should be
reflected through the entity that they are paying to provide operational
cloud services.  It's those directly consuming the code from openstack.org
that are responsible here because they are the ones directly making money
by either providing public/private cloud services, or reselling a
productized OpenStack or providing consulting services and the like.

This should not stop users/operators from contributing information,
requirements or code in any way.  But if they have to go around their
vendor then that vendor has failed them.

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150210/c68d929c/attachment.html>