> On Feb 10, 2015, at 9:21 AM, Dean Troyer <dtro...@gmail.com> wrote:
> On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) 
> <kevin...@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 

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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to