Open Stack

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