Open Stack

> On Feb 10, 2015, at 9: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.]

No offense taken! I just wanted to start a conversation about it, so mission accomplished :-D

> 
> 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.

100% agree, which really is my entire point. 

I also noticed that since the original message went out, it's been clarified that "current release" is meant to mean "any OpenStack contributions during the current release cycle" (paraphrase based on my reading of the clarification), which would include stable branches.  I'm personally OK with this. I don't think the foundation should cover the cost of anyone who's contributed even a single bug fix in the last year (or whatever time period). Mostly I just want to make sure we're not scaring people away from working on stable branches. Like we've stipulated, maintenance isn't a lot of fun nor is it high profile. If we don't give people an incentive to do it, it's entirely likely they'll just say screw it.

> * 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.

Also agree. The only reason I mention it is that, as you stated, a lot of companies use it as a metric, and it does matter. If you want to get an OpenStack related job, chances are if you don't show up in Stack Analytics, you're going to have a harder time of it.

Jeremy made a good point that we should work that out with SA, which is unrelated to "OpenStack" specifically. Perhaps it's just a matter of better documenting how to properly commit to stable branches if you want it to be tracked.

> * 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.

Again, I completely agree. But, as we've seen companies like to tout what they're doing. I personally do a lot of work on the stable branches, upstream when I can, but a lot of times I'm doing work on stuff that's been EOL or for which the issue I'm working on isn't considered "stability work". In those cases my work never goes upstream. Combine this with the SA issues, and that's a lot of out of band work.

> 
> 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.

This, I disagree with. Not only does it make the assumption that anyone running OS "for profit" is either chasing trunk or paying a vendor, but it creates a potential fragmentation nightmare and chokes down the number of entities willing to invest into the project.

If I'm paying vendor X for operational cloud services, and it's stated that they're who should be voicing my interests in the community 1) What happens when my interests and that of another customer of vendor X conflict? But 2) Why should I invest in the community? I'm paying a vendor, it's their problem. In fact, why do I even have operators who could potentially contribute useful information? I'm paying a vendor, it's their problem. Then, that vendor is going to do what they can to stabilize things with the limited resources they have. So they're less incentivized to work out issues upstream. They're just going to do their own thing and now we're back to "What is OpenStack?" complete with all the 3rd party integration "what should I code against" issues, multiple stable branches maintained by individual vendors, etc.

Whatever the case, it just feels like there's a huge focus on master. And that's good, but we need to figure out what we're going to do about those not chasing trunk. If we make it too hard for them I believe it eventually ends badly for all of us and I love this project too much to be OK with feeling that way :-D

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