Open Stack

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

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

The sentiment that Kevin is expressing here has come up informally at past Operator’s meetups as well, which makes sense given that relatively few operators are chasing trunk vs using a stable release.  I would hypothesize that there’s probably actually a fair bit of interest among operators in having well maintained stable branches but there are disincentives that keep them from pitching in more.  Let’s see if we can bring that to light a bit—I’ve added an item on the etherpad to discuss this in Philadelphia at the Operator’s midcycle meetup in a few weeks. [1]  If folks who are attending aren’t familiar with the current stable branch policies and team structure, you may want to read through the wiki first. [2]

[1] https://etherpad.openstack.org/p/PHL-ops-meetup

[2] https://wiki.openstack.org/wiki/StableBranch

At Your Service,

Mark T. Voelker
OpenStack Architect

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

Since this is sort of a topic change, I opted to start a new thread. I was reading over the "Juno is Fubar at the Gate" thread, and this bit stood out to me:

So I think it's time we called the icehouse branch and marked it EOL. We
originally conditioned the longer support window on extra people stepping
forward to keep things working. I believe this latest issue is just the latest
indication that this hasn't happened. Issue 1 listed above is being caused by
the icehouse branch during upgrades. The fact that a stable release was pushed
at the same time things were wedged on the juno branch is just the latest
evidence to me that things aren't being maintained as they should be. Looking at
the #openstack-qa irc log from today or the etherpad about trying to sort this
issue should be an indication that no one has stepped up to help with the
maintenance and it shows given the poor state of the branch.

Most specifically: 

"We originally conditioned the longer support window on extra people stepping forward to keep things working ... should be an indication that no one has stepped up to help with the maintenance and it shows given the poor state of the branch".

I've been talking with a few people about this very thing lately, and I think much of it is caused by what appears to be our actively discouraging people from working on it. Most notably, 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. I've personally gotten a few commits into stable, but have nothing to show for it in stack-analytics (if I'm doing it wrong, I'm happy to be corrected).

My point here isn't to complain that I, or others, are not getting credit, but to point out that I don't know what we expected to happen to stable branches when we actively dis-incentivize people from working on them. Working on hardening old code is generally far less interesting than working on the cool shiny new features, and many of the productionalization issues we run into aren't uncovered until it's being run at scale which in turn is usually by a big company who likely isn't chasing trunk.

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.

- - -- Kevin
__________________________________________________________________________
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

iQIcBAEBCgAGBQJU2i1eAAoJELUJLUWGN7CbmPEQAKV/9RPgKt6jwvq0bzhFCJPF
hz2LOC8M5Fk1wINGUcvwGjiphCwGMSD9p6IYx7PAzMrnbhLqQa0exCmo4DUi3jdV
qNC1A6juScrHjyQMcQ3dBS4Z4QEh0S964n2Ae/uoWydpDe8WGy4DQRLTNy+mCIg5
ROManHAWcQ3Cr5fYkFSeGQgaoROypj2Eebvv4kiYDPQVkjK1o49hpybxe5v0zR/Y
6kuacoZCK8h6X8b4CrbG+t/vCy8dqWIUB1j67VBojRDpe1p0yQqA3IJ72DLPfTw5
0GzUecfW781ZP5fHQSwhbg7t31UYXBpo9xszltXBiNynHRktA7BwYwj+YAFCKgNZ
sQ/gZOruqR+Os8/+pngA23PCGvuCUsTamUCkQUs4mCHjdvPq/BNFg0qGNeeheLQq
CzlldwqcPY5py3KfmipIZakH1wZ2S/DU/snuAhVatTjVHqO1leyk5asHYVVAnwCQ
96vawAHcIXEN4dPcXpcYBiiTE1mgq+0FQgVGsr4fQ2BkRYDN9rmOdVp+mG7b7QM0
jhK+POQqj+ojnQOKwA2ygQUglDY8MxjmfCrMukkWQylmYVb09Z0cOMFfMMw7YfU3
pWGP6BIfCManduqVBqFvTMxh/dCGIGq3LwrXo23qmukdgSIVRuj16XPZqXZ5xtv/
A6NV//pQXxvO4d+l4bBk
=cT3X
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU2i1jAAoJELUJLUWGN7CbsDIP/i0CyFC1FOL7SSC3IFLvVd9r
sJw/AmH4e5oc0FwBlyF6PJa4vqhK3SYMRE1/mOUs/zpM8IRrMafkf83w2aSYrskw
5kYYYOyv702bmuKjnCK75Z6/DgzkdkbfhL1leLsEPNzjSlOHef139Bsy6SmAx9lO
xqkiAP4QGdvtrEIfz9IWeUiPipYAocDa2oQkbtzsUB2B0eoI4yQY4euLxso7IpeI
pZiw0mMdkARM6KHLIvg7o4mcqC4VmhcRLQQxnfgqH6xtRfWI7XbUuSPv5HIKLLP0
/EDRDTxdNoF9EC8TRz1LF9VEdjx1v4JrK0+WHtW6sTKKW47+QF79ogbaJKtyY7ry
LaWrqbxdHsXvXftNv0muPQKUWfibSQqzhJLFeyLjhh3IW9AODllRj/oFfEqIYXl/
C103F65QkZqx2Njg0x+C88c/Md7gmrJtZQs+1+Sf5uNaj59NwLS0nPJaoqvZYiLp
/T8IDgn1iJPk+J6pnmfOKC5Iafw2HxW95ymYnPHytW05uznZ1ZAcR8YZVhqQeteT
j+eQj6pFzJxtCfPeQp+PgegSS1esMdMAHlUEpaqg/uh7fp0JT8KZtAk1hBqmf+kG
9NLfnIWMMtD3DjMS5ubUQJ40QU7dZsojcnn2Y76cTkHCLGw7IhxEtPUEQJpx0bb3
dX4GdnjTdXHFWZmo1O2j
=jcPx
-----END PGP SIGNATURE-----