[openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate) [metrics]

Mark Voelker mvoelker at vmware.com
Tue Feb 10 17:30:01 UTC 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

The voice of operators/users/deployers in this conversation should be reflected through the entity that they are paying to provide operational cloud services.  

Let’s be careful here: I hope you didn’t mean to say that operators/users/deployers voices should only be heard when they pay a vendor to get OpenStack (and I don’t think you did, but it read that way a bit).  

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.

Sure, I agree those folks certainly have an interest...but I don’t believe it’s solely their responsibility and that "the development community" has none.  If the development community has no responsibility for maintaining stable code, why have stable branches at all?  If we aren’t incentivizing contributions to stable code, we’re encouraging forking, IMHO.  There’s a balance to be struck here.  I think what’s being voiced in this thread is that we haven’t gotten to that place yet where there are good incentives to contribute to stable branch (not just back porting fixes, but dealing with gate problems, etc as well) and we’d like to figure out how to improve that situation.

At Your Service,

Mark T. Voelker
OpenStack Architect

On Feb 10, 2015, at 11:21 AM, Dean Troyer <dtroyer at gmail.com> wrote:

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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU2kAYAAoJELUJLUWGN7CbJpEQAJJmw/RlgRMxVSyuWZpcvJmn
nWVLw3KJTspGz5V9clFG6QYgDR5ygWNz51e+QT0Ps+baOWxq9Figwur2yyYfOt8c
hissfjL+OPG2QRrAQOwys7n2s5bSb28ePvO+/benY1PykAknpZX4lq28V4gfqRX9
+2ZjxNs+orkj0cuDi1KdhZPjfo1fuZ07GgCjFy1Xuqq7rYBLfrkEffmF2dbxF67R
aHxbTWe9CgX6IlTL1p5rH7wCKyYQrkFUEXXG3w3CpdWJQ4Ky2bvC/JyKX8wFOkqp
AL7voCvG0zwPV+BHBVabqobC7qb+7+uYd6IQRovuxVxcl9ZdI0o9GQyhcXf890IQ
Sq8Z+PApzOvd8pxQdpq0SBYlVZUsjuBe3YGfvmHg/3hyto+FUzKhJOfjfLepST5U
tThEQzSnfZwfgnTkI3/rN9zMvlg7vsP15lRJzRx+ycQhyzTJZdlEiA+yIQF3tdrZ
h1ZW1M4Dc9R/R56jRV3YeSxY1wMUlBHm4Gn+uKVS3q/dKjIOkYjJEEDVcDd/wCYh
Uknp5GFsZi6Uvj0Dgymllrk7HCustzEhog4r0mORH6W0HtYVK0U/NvaRFXkF/VS0
4aWArCzC603glUMNIdD8x6Nw5LTXK16ENk9OoXRan8Y9fNQU0igIqLLYymXc1AIP
5refDM8yhQxc2/ErLYT6
=Xpbq
-----END PGP SIGNATURE-----


More information about the OpenStack-dev mailing list