Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Flavio Percoco]

Ok, as promissed I've pushed a patch with a reference document that collects
what I had written in my post and the feedback from this thread.

I believe the patch needs tons of discussion so, y'all, get to it :)

I've added members from different teams to help filling in some of the sections
specific for their teams.

https://review.openstack.org/398875

Thanks,
Flavio

On 07/11/16 09:09 -0800, Flavio Percoco wrote:

Greetings,

I literally just posted a thing on my blog with some thoughts of what I'd expect
any new language being proposed for OpenStack to cover before it can be
accepted.

The goal is to set the expectations right for what's needed for new languages to
be accepted in the community. During the last evaluation of the Go proposal I
raised some concerns but I also said I was not closed to discussing this again
in the future. It's clear we've not documented expectations yet and this is a
first step to get that going before a new proposal comes up and we start
discussing this topic again.

I don't think a blog post is the "way we should do this" but it was my way to
dump what's in my brain before working on something official (which I'll do
this/next week).

I also don't think this list is perfect. It could either be too restrictive or
too open but it's a first step. I won't paste the content of my post in this
email but I'll provide a tl;dr and eventually come back with the actual
reference document patch. I thought I'd drop this here in case people read my
post and were confused about what's going on there.

Ok, here's the TL;DR of what I believe we should know/do before accepting a new
language into the community:

- Define a way to share code/libraries for projects using the language
- Work on a basic set of libraries for OpenStack base services
- Define how the deliverables are distributed
- Define how stable maintenance will work
- Setup the CI pipelines for the new language

The longer and more detailed version is here:

https://blog.flaper87.com/embracing-other-languages-openstack.html

Stay tuned,
Flavio

--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Thierry Carrez]

Pete Zaitcev wrote:
> I'm disappointed that TC voted Golang
> down on August 2, but I can see where they come from.
> 
> The problem we're grappling with on the Swift side is (in my view) mainly
> that the Go reimplementation provides essential performance advantages
> which manifest at a certain scale (around 100 PB with current technology).
> For this reason, ignoring Hummingbird and prohibiting Go is not going to
> suppress them. As the operators deploy Hummingbird in preference to the
> Python implementation, the focus of the development is going to migrate,
> and the end result is going to be an effective exile of a founding
> project from the OpenStack.

Yes, and those same performance advantages are why so many people (yes,
including TC members) are uncomfortable with the current state. There is
no question (I think) that Swift would benefit from being able to
include Go-rewritten parts. We just need to make sure that what is a
benefit for Swift doesn't turn out to be a disaster for "OpenStack".

This is in my opinion the real reason for the "not yet" answer that was
given so far -- lack of visibility into what a Go-enabled OpenStack
would look like in the future. The clearer we are with what that future
would look like (not just for Swift for for "OpenStack" as a whole), and
the more people we have lined up to do the necessary work to turn that
specific case into a general success, the more likely it is that a
majority of TC members (who have "OpenStack" interests at heart beyond
any specific project) will support that addition to our toolbelt.

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Pete Zaitcev's message of 2016-11-10 11:00:27 -0700:
> On Wed, 9 Nov 2016 11:14:32 + (GMT)
> Chris Dent  wrote:
> 
> > The conversations about additional languages in this community have
> > been one our most alarmingly regressive and patronizing. They seem
> > to be bred out of fear rather than hope and out of lack of faith in
> > each other than in trust. We've got people who want to build stuff.
> > Isn't that the important part?
> 
> I dunno, it seems fine to discuss. I'm disappointed that TC voted Golang
> down on August 2, but I can see where they come from.
> 
> The problem we're grappling with on the Swift side is (in my view) mainly
> that the Go reimplementation provides essential performance advantages
> which manifest at a certain scale (around 100 PB with current technology).
> For this reason, ignoring Hummingbird and prohibiting Go is not going to
> suppress them. As the operators deploy Hummingbird in preference to the
> Python implementation, the focus of the development is going to migrate,
> and the end result is going to be an effective exile of a founding
> project from the OpenStack.

That doesn't have to be the case. I don't want to speak for anyone
else on the TC, but my reason for saying "not yet" was a lack of
faith that some of the issues Flavio is putting together will be
addressed in the process of trying to add Go to the community.  My
request has been to demonstrate not just that Swift needs Go, but
that Swift is willing to help the rest of the community in the
adoption. I'm starting to see signs of that happening, for example
with some discussions about how oslo.config can be used in the
current version of swift.

> (Even if happens, it's probably not a big deal. Just look how well Ceph
> is doing, community-wise. Operators aren't crying bloody tears either,
> do they?)
> 
> The conflict is that since re-writing e.g. Newtron in Go does not confer
> the same performance advantage (AFAIK -- your VLANs aren't going to set
> up and tear down 80 times faster), the disruption isn't worth the trouble
> for the majority of OpenStack projects. This is why TC voted us down.

That is not why I voted against the most recent request.

> And the talk about the community is mostly there to heal psychologically.

I'm not sure what you mean by that sentence. Can you rephrase it?

> So, it wasn't "regressive" or "patronizing", just business. See how Flavio
> outlined specific steps in a constructive manner.
> 
> I'm quite glad that Ash wants to do something about CI. And I'm going
> to look into fully supporting existing configurations. Maybe share it with
> Designate and thus create something like a proto-"oslo.go.config".
> Of course we need to have some code to share first.

That's good news, thank you.

> 
> -- Pete
> 

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Davanum Srinivas]

Pete,

Please see below:

On Thu, Nov 10, 2016 at 1:00 PM, Pete Zaitcev  wrote:
> On Wed, 9 Nov 2016 11:14:32 + (GMT)
> Chris Dent  wrote:
>
>> The conversations about additional languages in this community have
>> been one our most alarmingly regressive and patronizing. They seem
>> to be bred out of fear rather than hope and out of lack of faith in
>> each other than in trust. We've got people who want to build stuff.
>> Isn't that the important part?
>
> I dunno, it seems fine to discuss. I'm disappointed that TC voted Golang
> down on August 2, but I can see where they come from.
>
> The problem we're grappling with on the Swift side is (in my view) mainly
> that the Go reimplementation provides essential performance advantages
> which manifest at a certain scale (around 100 PB with current technology).
> For this reason, ignoring Hummingbird and prohibiting Go is not going to
> suppress them. As the operators deploy Hummingbird in preference to the
> Python implementation, the focus of the development is going to migrate,
> and the end result is going to be an effective exile of a founding
> project from the OpenStack.
>
> (Even if happens, it's probably not a big deal. Just look how well Ceph
> is doing, community-wise. Operators aren't crying bloody tears either,
> do they?)
>
> The conflict is that since re-writing e.g. Newtron in Go does not confer
> the same performance advantage (AFAIK -- your VLANs aren't going to set
> up and tear down 80 times faster), the disruption isn't worth the trouble
> for the majority of OpenStack projects. This is why TC voted us down.
> And the talk about the community is mostly there to heal psychologically.

Please read the long comment from Doug Hellmann: (time stamp Aug 2 5:01 PM)
https://review.openstack.org/#/c/339175/

> So, it wasn't "regressive" or "patronizing", just business. See how Flavio
> outlined specific steps in a constructive manner.
>
> I'm quite glad that Ash wants to do something about CI. And I'm going
> to look into fully supporting existing configurations. Maybe share it with
> Designate and thus create something like a proto-"oslo.go.config".
> Of course we need to have some code to share first.
>
> -- Pete
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Joshua Harlow]

Ed Leafe wrote:

On Nov 9, 2016, at 5:14 AM, Chris Dent  wrote:


Something that feels like it gets under-emphasised in this conversation
is that change is coming whatever we do. As a community we can either
move quickly and stay ahead of the change and see it as a productive
development that we can surf or we can dilly dally and get drowned by a
wave that collapses over us.

Ecosystems must evolve and change because the world evolves and changes.
If we try to control this stuff too much what we will be doing is taking
the oxygen out of the system and snuffing the flame of excitement and
innovation.


That is, of course, a series of obvious statements. We need to change or die.

What I think is missing from this conversation is that there are a lot of 
people who are used to the way things happen in the startup world, where you 
get an idea, work like crazy to get an MVP out the door, and then iterate from 
there. The problem is that OpenStack is the exact opposite of a startup; it’s a 
giant legacy application.



That's only because some (? I'm not sure who they are ?) believe this is 
the way that it *must* be. There are also folks that don't believe this 
is the way it needs to be (including myself), though I get what u are 
saying.



Don’t like the word “legacy”? Well, what would you call something that has to 
support users who haven’t upgraded in several years? What would you call 
something that can never have a greatly-improved but backwards-incompatible 
change? Sure, that might be possible in some of the add-ons for the OpenStack 
ecosystem, but for any of the core projects (yes, I said that word), that is 
simply not an option.

> So yes, of course we’re going to drive off those who want to work 
with the coolest and latest stuff. This isn’t “exciting” work in that 
sense of the word.


I understand what u are saying with the above, but I don't necessarily 
feel it is something we as a community can not resolve (fate is what we 
make).


Why aren't we asking the question of why can't we figure out a way to do 
breaking changes, why can't we move quicker... Instead of assuming there 
is no way that can happen, what happens if we ask ourselves 'what are 
the ways we can make such a thing happen, what are the reasons people 
are stuck on releases of several years behind...' and work through 
fixing those.


Perhaps that involves some very tough questions and perhaps some 
potentially 'radical' answers, but so what... I'd rather have those 
kinds of questions than just assume we are all stuck doing not exciting 
work on some legacy application(s) that never change because existing 
users are stuck.


I mean if we get stuck in the support X users of things for all of time, 
we sort of miss out on the Y users that we can gain by fixing it (even 
if such changes are radical) and making it better; perhaps at the end u 
get X + Y users total (which is even better) or perhaps u don't and u 
move on and learn from the attempt.


-Josh

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Pete Zaitcev]

On Wed, 9 Nov 2016 11:14:32 + (GMT)
Chris Dent  wrote:

> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?

I dunno, it seems fine to discuss. I'm disappointed that TC voted Golang
down on August 2, but I can see where they come from.

The problem we're grappling with on the Swift side is (in my view) mainly
that the Go reimplementation provides essential performance advantages
which manifest at a certain scale (around 100 PB with current technology).
For this reason, ignoring Hummingbird and prohibiting Go is not going to
suppress them. As the operators deploy Hummingbird in preference to the
Python implementation, the focus of the development is going to migrate,
and the end result is going to be an effective exile of a founding
project from the OpenStack.

(Even if happens, it's probably not a big deal. Just look how well Ceph
is doing, community-wise. Operators aren't crying bloody tears either,
do they?)

The conflict is that since re-writing e.g. Newtron in Go does not confer
the same performance advantage (AFAIK -- your VLANs aren't going to set
up and tear down 80 times faster), the disruption isn't worth the trouble
for the majority of OpenStack projects. This is why TC voted us down.
And the talk about the community is mostly there to heal psychologically.

So, it wasn't "regressive" or "patronizing", just business. See how Flavio
outlined specific steps in a constructive manner.

I'm quite glad that Ash wants to do something about CI. And I'm going
to look into fully supporting existing configurations. Maybe share it with
Designate and thus create something like a proto-"oslo.go.config".
Of course we need to have some code to share first.

-- Pete

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Clint Byrum]

Excerpts from Chris Dent's message of 2016-11-10 15:54:39 +:
> On Thu, 10 Nov 2016, Clint Byrum wrote:
> > Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:
> >> Let's just get on with making stuff and work out the problems (and of
> >> course there will be many, there always are) as they happen. That's
> >> what we do.
> >
> > Apologies for the stretched analogy. What you're suggesting is that we go
> > build without building codes and without a city plan, because there's a
> > market force that we must capture. But when we let the tenants move in
> > (the operators) and the other tenants sewers back up and their roads
> > are backed up with traffic, we'll just deal with that later. I don't
> > think that's fair to anyone.
> 
> Sorry, I think you are extrapolating _far_ too much from what I've
> said. I've not said we should have no plan, no process, anarchy,
> cats and dogs living together[1]. I've said we should work out the
> problems as we go.
> 
> The current process to create a plan (nevermind actually following
> it) is weighted (to me) too far in the direction of trying to be
> prepared for as much as possible. That's a recipe for getting it
> wrong; because we are humans who can't see the future.
> 

Agreed, probably went a bit far there.

> > I don't think we have to have a PERFECT plan, but we need to _acknowledge_
> > that this is the price of diversity and expansion. I personally think
> > it's worth it, but let's own the chaos and at least start with a rough
> > hypothesis of how each new language might effect the overall system, and
> > a plan to measure and react quickly.
> 
> Yes, let's talk about it and acknowledge it. There will be a price
> of diversity and expansaion, yes. I'm very happy to hear that you
> agree it is worth it. I'm also happy to hear you acknowledge that
> it will be chaotic.
> 
> However -- to push the current thread further into the extreme than it
> actually is, to make a point -- we don't need to reimplement oslo in
> every candidate language before we actually build and distribute
> something useful with real users in whatever that language might be.
> We've got to have some faith in ourselves as developers, users and
> operators that we have the capacity to adapt and learn for sake of new
> stuff that is good.
> 

It actually sounds like we agree on most if not all fundamental points.

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Ed Leafe]

On Nov 9, 2016, at 5:14 AM, Chris Dent  wrote:

> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
> 
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.

That is, of course, a series of obvious statements. We need to change or die.

What I think is missing from this conversation is that there are a lot of 
people who are used to the way things happen in the startup world, where you 
get an idea, work like crazy to get an MVP out the door, and then iterate from 
there. The problem is that OpenStack is the exact opposite of a startup; it’s a 
giant legacy application.

Don’t like the word “legacy”? Well, what would you call something that has to 
support users who haven’t upgraded in several years? What would you call 
something that can never have a greatly-improved but backwards-incompatible 
change? Sure, that might be possible in some of the add-ons for the OpenStack 
ecosystem, but for any of the core projects (yes, I said that word), that is 
simply not an option.

So yes, of course we’re going to drive off those who want to work with the 
coolest and latest stuff. This isn’t “exciting” work in that sense of the word. 

-- Ed Leafe






__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Flavio Percoco]

On 10/11/16 15:54 +, Chris Dent wrote:

On Thu, 10 Nov 2016, Clint Byrum wrote:

Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:

Let's just get on with making stuff and work out the problems (and of
course there will be many, there always are) as they happen. That's
what we do.


Apologies for the stretched analogy. What you're suggesting is that we go
build without building codes and without a city plan, because there's a
market force that we must capture. But when we let the tenants move in
(the operators) and the other tenants sewers back up and their roads
are backed up with traffic, we'll just deal with that later. I don't
think that's fair to anyone.


Sorry, I think you are extrapolating _far_ too much from what I've
said. I've not said we should have no plan, no process, anarchy,
cats and dogs living together[1]. I've said we should work out the
problems as we go.

The current process to create a plan (nevermind actually following
it) is weighted (to me) too far in the direction of trying to be
prepared for as much as possible. That's a recipe for getting it
wrong; because we are humans who can't see the future.


I don't think we have to have a PERFECT plan, but we need to _acknowledge_
that this is the price of diversity and expansion. I personally think
it's worth it, but let's own the chaos and at least start with a rough
hypothesis of how each new language might effect the overall system, and
a plan to measure and react quickly.


Yes, let's talk about it and acknowledge it. There will be a price
of diversity and expansaion, yes. I'm very happy to hear that you
agree it is worth it. I'm also happy to hear you acknowledge that
it will be chaotic.

However -- to push the current thread further into the extreme than it
actually is, to make a point -- we don't need to reimplement oslo in
every candidate language before we actually build and distribute
something useful with real users in whatever that language might be.
We've got to have some faith in ourselves as developers, users and
operators that we have the capacity to adapt and learn for sake of new
stuff that is good.


If you mean Oslo as the team that manages the shared code across projects then
yes, I think we have to and we need a way for sharing code. If instead you mean
oslo libraries then no, I don't think we need to re-implement them all in the
new language. What we need, however, is to guarantee compatibility for operators
and other devs. Having inconsistencies in the way config files are managed, the
RPC protocol is implemented, messages are logged is a recipe for a chaotic
adoption of the new language. This is what I'd like us to avoid.

There's some work that needs to be done up-front. I agree the discussion of
adding new languages have nnot been perfect but that's also what we do. We
evaluate our options, we study, we work out a way to embrace change and
innovate. That's what I'm trying to do here, work out a way for us to embrace
new languages and move on to the next change.

As Clint put ir, we need to own the change and the chaos that will come with it.
Not having these processes would just make it unmanageable for everyone.

Flavio


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Pete Zaitcev]

On Mon, 07 Nov 2016 15:53:51 -0800
Joshua Harlow  wrote:

> Standards though exist for a reason (and ini files are pretty common 
> across languages and such); though of course oslo.config has some very 
> tight integration with openstack, the underlying ini concept it 
> eventually reads/writes really isn't that special (so hopefully such a 
> thing existing isn't that hard).

Swift in Go demonstrated that it's not the ini format that's the problem
for reimplementation, the paste-deploy is. In particular, the names from
pipeline= define section names, and egg names define what code is executed.
So one can have "pipeline=keystone app", but [keystone] section is actually
use=egg:swift#tempauth, not Keystone. It's pefectly legal and will work
today, even if such a configuration is a hostile move against future
coworkers.

-- Pete

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Chris Dent]

On Thu, 10 Nov 2016, Clint Byrum wrote:

Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:

Let's just get on with making stuff and work out the problems (and of
course there will be many, there always are) as they happen. That's
what we do.


Apologies for the stretched analogy. What you're suggesting is that we go
build without building codes and without a city plan, because there's a
market force that we must capture. But when we let the tenants move in
(the operators) and the other tenants sewers back up and their roads
are backed up with traffic, we'll just deal with that later. I don't
think that's fair to anyone.


Sorry, I think you are extrapolating _far_ too much from what I've
said. I've not said we should have no plan, no process, anarchy,
cats and dogs living together[1]. I've said we should work out the
problems as we go.

The current process to create a plan (nevermind actually following
it) is weighted (to me) too far in the direction of trying to be
prepared for as much as possible. That's a recipe for getting it
wrong; because we are humans who can't see the future.


I don't think we have to have a PERFECT plan, but we need to _acknowledge_
that this is the price of diversity and expansion. I personally think
it's worth it, but let's own the chaos and at least start with a rough
hypothesis of how each new language might effect the overall system, and
a plan to measure and react quickly.


Yes, let's talk about it and acknowledge it. There will be a price
of diversity and expansaion, yes. I'm very happy to hear that you
agree it is worth it. I'm also happy to hear you acknowledge that
it will be chaotic.

However -- to push the current thread further into the extreme than it
actually is, to make a point -- we don't need to reimplement oslo in
every candidate language before we actually build and distribute
something useful with real users in whatever that language might be.
We've got to have some faith in ourselves as developers, users and
operators that we have the capacity to adapt and learn for sake of new
stuff that is good.

[1] This is in fact a world I might want to live in, I like cats and
dogs and dood, anarchy now, please. But I wouldn't presume to impose
that here.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Clint Byrum]

Excerpts from Chris Dent's message of 2016-11-09 11:14:32 +:
> On Tue, 8 Nov 2016, Ash wrote:
> 
> > I couldn't agree more. I don't like change for the sake of change (in any
> > aspect of my life). So in my mind this would have to be a way to better
> > bind us.
> 
> Here, have some tortured metaphors:
> 
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
> 
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
> 
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
> 

What you argue for above, is anarchy. The rules are not what binds us,
our will is. However, the rules are what helps us preserve and grow the
commons that we all share.

It seems like there is enough will to expand the scope of the rules,
but we all must acknowledge that doing so will also require expanding
the commons, and be prepared for the strain that will put on the existing
infrastructure.

And I don't just mean "infra". I mean the infrastructure of python
development knowledge, deployer understanding, and overall communication
overhead.

> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
> 
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
> 

Apologies for the stretched analogy. What you're suggesting is that we go
build without building codes and without a city plan, because there's a
market force that we must capture. But when we let the tenants move in
(the operators) and the other tenants sewers back up and their roads
are backed up with traffic, we'll just deal with that later. I don't
think that's fair to anyone.

I don't think we have to have a PERFECT plan, but we need to _acknowledge_
that this is the price of diversity and expansion. I personally think
it's worth it, but let's own the chaos and at least start with a rough
hypothesis of how each new language might effect the overall system, and
a plan to measure and react quickly.

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Wiegley]

> On Nov 10, 2016, at 7:24 AM, Russell Bryant  wrote:
> 
> 
> 
> On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  > wrote:
> On Tue, 8 Nov 2016, Ash wrote:
> 
> I couldn't agree more. I don't like change for the sake of change (in any
> aspect of my life). So in my mind this would have to be a way to better
> bind us.
> 
> Here, have some tortured metaphors:
> 
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
> 
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
> 
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
> 
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
> 
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
> 
> ​Agreed, Chris.  I think this topic has reflected quite poorly on OpenStack, 
> so far.

Also agreed. Like it or not, this topic is a proxy debate for whether it’s 
worth the risk to invest in OpenStack for new things. And doubling down on more 
process is not sending a great message.

Thanks,
doug

> 
> -- 
> Russell Bryant
> __
> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Russell Bryant]

On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  wrote:

> On Tue, 8 Nov 2016, Ash wrote:
>
> I couldn't agree more. I don't like change for the sake of change (in any
>> aspect of my life). So in my mind this would have to be a way to better
>> bind us.
>>
>
> Here, have some tortured metaphors:
>
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
>
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
>
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
>
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
>
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.
>

​Agreed, Chris.  I think this topic has reflected quite poorly on
OpenStack, so far.

-- 
Russell Bryant
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Clay Gerrard]

On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  wrote:

>
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
>

Here here!
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Ash]

On Wed, Nov 9, 2016 at 3:14 AM, Chris Dent  wrote:

> On Tue, 8 Nov 2016, Ash wrote:
>
> I couldn't agree more. I don't like change for the sake of change (in any
>> aspect of my life). So in my mind this would have to be a way to better
>> bind us.
>>
>
> Here, have some tortured metaphors:
>
> Something that feels like it gets under-emphasised in this conversation
> is that change is coming whatever we do. As a community we can either
> move quickly and stay ahead of the change and see it as a productive
> development that we can surf or we can dilly dally and get drowned by a
> wave that collapses over us.
>
> Ecosystems must evolve and change because the world evolves and changes.
> If we try to control this stuff too much what we will be doing is taking
> the oxygen out of the system and snuffing the flame of excitement and
> innovation.
>
> As a community we don't want to be bound together by rules, we want
> to be enabled by processes that support making and doing things
> effectively. The things that we make and do is what binds us
> together.
>
> The conversations about additional languages in this community have
> been one our most alarmingly regressive and patronizing. They seem
> to be bred out of fear rather than hope and out of lack of faith in
> each other than in trust. We've got people who want to build stuff.
> Isn't that the important part?
>
> Let's just get on with making stuff and work out the problems (and of
> course there will be many, there always are) as they happen. That's
> what we do.


Well said, Chris!

>
>
> --
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Chris Dent]

On Tue, 8 Nov 2016, Ash wrote:


I couldn't agree more. I don't like change for the sake of change (in any
aspect of my life). So in my mind this would have to be a way to better
bind us.


Here, have some tortured metaphors:

Something that feels like it gets under-emphasised in this conversation
is that change is coming whatever we do. As a community we can either
move quickly and stay ahead of the change and see it as a productive
development that we can surf or we can dilly dally and get drowned by a
wave that collapses over us.

Ecosystems must evolve and change because the world evolves and changes.
If we try to control this stuff too much what we will be doing is taking
the oxygen out of the system and snuffing the flame of excitement and
innovation.

As a community we don't want to be bound together by rules, we want
to be enabled by processes that support making and doing things
effectively. The things that we make and do is what binds us
together.

The conversations about additional languages in this community have
been one our most alarmingly regressive and patronizing. They seem
to be bred out of fear rather than hope and out of lack of faith in
each other than in trust. We've got people who want to build stuff.
Isn't that the important part?

Let's just get on with making stuff and work out the problems (and of
course there will be many, there always are) as they happen. That's
what we do.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Ash]

On Tue, Nov 8, 2016 at 2:27 AM, Thierry Carrez 
wrote:

> Ash wrote:
> > [...]
> > Here's another take on the situation. If there are people who genuinely
> > wish to see a CI pipeline that can support something like Go, perhaps
> > you can establish a prerequisite of working with the Infra team on
> > establishing the new pipeline. In my opinion, this seems to be the major
> > gate. So, if there's a clear path identified, resources provided, and
> > the Infra team is ultimately benefitted, then I'm not sure why there
> > should be another rejection. Just a thought. I know this proposal
> > continues to come up and I'm a big fan of seeing other languages
> > supported, especially Go. But I also understand that it can break
> > things. Personally, I would even volunteer to work on such an Infra
> effort.
> >
> > BTW, it is quite possible that another group might feel the same
> > constraints. It's perfectly reasonable. But if we can overcome such
> > obstacles, would the TC still have a concern?
>
> The TC isn't just one person. In complex situations like this where you
> have to weigh the trade-off between opening up more choices and our
> community's ability to digest/survive the change, there will always be a
> wide variety of opinions. I won't claim to be able to predict how the
> current membership would vote.
>
> That said, I think that if we can have more confidence that our
> structure can handle it (from infra to release/stable/dep management)
> and that the OpenStack community will share expertise and best practices
> on Go and avoid reinventing the wheel in every project, I expect a
> majority of TC members to take that leap of faith.
>
> To me, the important part is that introducing Go should not be another
> way for some of our community to be different, but another way for our
> community to be one. It should do more to bind our community together
> than to split it into more factions and silos.
>

I couldn't agree more. I don't like change for the sake of change (in any
aspect of my life). So in my mind this would have to be a way to better
bind us.

>
> --
> Thierry Carrez (ttx)
>
> __
> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2016-11-08 08:33:41 -0800:
> On 08/11/16 16:20 +, Hayes, Graham wrote:
> >On 08/11/2016 15:55, Doug Hellmann wrote:
> >> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
> >>> On 08/11/2016 10:30, Thierry Carrez wrote:
>  Ash wrote:
> > [...]
> > Here's another take on the situation. If there are people who genuinely
> > wish to see a CI pipeline that can support something like Go, perhaps
> > you can establish a prerequisite of working with the Infra team on
> > establishing the new pipeline. In my opinion, this seems to be the major
> > gate. So, if there's a clear path identified, resources provided, and
> > the Infra team is ultimately benefitted, then I'm not sure why there
> > should be another rejection. Just a thought. I know this proposal
> > continues to come up and I'm a big fan of seeing other languages
> > supported, especially Go. But I also understand that it can break
> > things. Personally, I would even volunteer to work on such an Infra 
> > effort.
> >
> > BTW, it is quite possible that another group might feel the same
> > constraints. It's perfectly reasonable. But if we can overcome such
> > obstacles, would the TC still have a concern?
> 
>  The TC isn't just one person. In complex situations like this where you
>  have to weigh the trade-off between opening up more choices and our
>  community's ability to digest/survive the change, there will always be a
>  wide variety of opinions. I won't claim to be able to predict how the
>  current membership would vote.
> >>>
> >>> Yup - and the TC could possibly change half, (or even all) its members
> >>> during time it takes to get this work done.
> >>>
>  That said, I think that if we can have more confidence that our
>  structure can handle it (from infra to release/stable/dep management)
>  and that the OpenStack community will share expertise and best practices
>  on Go and avoid reinventing the wheel in every project, I expect a
>  majority of TC members to take that leap of faith.
> >>>
> >>> There was a bit of work done for the previous proposal, but the main
> >>> objections were not to do with any of points raised in this email /
> >>> blog. The objections were mainly cultural - about how it would impact
> >>> the community (which *is* very important), and the exactly why it was
> >>> needed for the projects who were asking.
> >>>
>  To me, the important part is that introducing Go should not be another
>  way for some of our community to be different, but another way for our
>  community to be one. It should do more to bind our community together
>  than to split it into more factions and silos.
> 
> >>>
> >>> I would agree - but I would ask that we find a way forward that does not
> >>> require huge amounts of up front work, for a gamble at the end of the
> >>> process, where the work could be written off for any number of other
> >>> reasons.
> >>>
> >>
> >> I agree that we need to be careful about how much up-front work is
> >> required. A plan to address some of these concerns seems like a
> >> minimum level, with commitment to handle the immediate items like
> >> infra resources for managing those changes. But it's hard to specify
> >> the right levels in the abstract, because so much depends on the
> >> situation, language, and teams involved.
> >>
> >> Doug
> >
> >This. I think trying to define objective rules, procedures, and
> >checklists for what is at the end of the a subjective decision is
> >not a great idea.
> >
> >Should the policy just be "If you want to add a new language, add an
> >item to the TC agenda. They will the discuss the overall proposal, and
> >may ask for more details in the following areas, the use case, or decide
> >that this is not a direction that the community should proceed towards."
> >
> >Or, you know, a well written version of ^.
> 
> This feels a lot like what we have today. I think the set of requirements must
> be written down and clear. The evaluation of the use case should still happen
> and it'd be better for it to happen before the up-front work is done. There 
> will
> always be work to do up front for any new language being added to the 
> community.
> 
> Also, for the evaluation of the use case, it'd be awesome to have the use case
> presented to the mailing list before the item is even added to the TC agenda. 
> I
> liked the review that other members of the community did with the Swift
> proposal.
> 
> Flavio
> 

Right. I like the idea of having a list of expectations for what would
need to be done *eventually* to fully support a new language. Then when
there's a concrete request, the discussion can focus on whether those
things apply and if so what the timing needs to be.

Doug

__
OpenStack Development Mailing 

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 16:39, Flavio Percoco wrote:
> On 08/11/16 16:20 +, Hayes, Graham wrote:
>> On 08/11/2016 15:55, Doug Hellmann wrote:
>>> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
 On 08/11/2016 10:30, Thierry Carrez wrote:
> Ash wrote:
>> [...]
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps
>> you can establish a prerequisite of working with the Infra team on
>> establishing the new pipeline. In my opinion, this seems to be the major
>> gate. So, if there's a clear path identified, resources provided, and
>> the Infra team is ultimately benefitted, then I'm not sure why there
>> should be another rejection. Just a thought. I know this proposal
>> continues to come up and I'm a big fan of seeing other languages
>> supported, especially Go. But I also understand that it can break
>> things. Personally, I would even volunteer to work on such an Infra 
>> effort.
>>
>> BTW, it is quite possible that another group might feel the same
>> constraints. It's perfectly reasonable. But if we can overcome such
>> obstacles, would the TC still have a concern?
>
> The TC isn't just one person. In complex situations like this where you
> have to weigh the trade-off between opening up more choices and our
> community's ability to digest/survive the change, there will always be a
> wide variety of opinions. I won't claim to be able to predict how the
> current membership would vote.

 Yup - and the TC could possibly change half, (or even all) its members
 during time it takes to get this work done.

> That said, I think that if we can have more confidence that our
> structure can handle it (from infra to release/stable/dep management)
> and that the OpenStack community will share expertise and best practices
> on Go and avoid reinventing the wheel in every project, I expect a
> majority of TC members to take that leap of faith.

 There was a bit of work done for the previous proposal, but the main
 objections were not to do with any of points raised in this email /
 blog. The objections were mainly cultural - about how it would impact
 the community (which *is* very important), and the exactly why it was
 needed for the projects who were asking.

> To me, the important part is that introducing Go should not be another
> way for some of our community to be different, but another way for our
> community to be one. It should do more to bind our community together
> than to split it into more factions and silos.
>

 I would agree - but I would ask that we find a way forward that does not
 require huge amounts of up front work, for a gamble at the end of the
 process, where the work could be written off for any number of other
 reasons.

>>>
>>> I agree that we need to be careful about how much up-front work is
>>> required. A plan to address some of these concerns seems like a
>>> minimum level, with commitment to handle the immediate items like
>>> infra resources for managing those changes. But it's hard to specify
>>> the right levels in the abstract, because so much depends on the
>>> situation, language, and teams involved.
>>>
>>> Doug
>>
>> This. I think trying to define objective rules, procedures, and
>> checklists for what is at the end of the a subjective decision is
>> not a great idea.
>>
>> Should the policy just be "If you want to add a new language, add an
>> item to the TC agenda. They will the discuss the overall proposal, and
>> may ask for more details in the following areas, the use case, or decide
>> that this is not a direction that the community should proceed towards."
>>
>> Or, you know, a well written version of ^.
>
> This feels a lot like what we have today. I think the set of requirements must
> be written down and clear. The evaluation of the use case should still happen
> and it'd be better for it to happen before the up-front work is done. There 
> will
> always be work to do up front for any new language being added to the 
> community.

Yes - and that sentence covers the initial use case discussion, and
also allows for the more subjective criteria to be evaluated before the
up front work is started.

 >> more details in the following areas

In my mind this would point to a list like the one presented here.

> Also, for the evaluation of the use case, it'd be awesome to have the use case
> presented to the mailing list before the item is even added to the TC agenda. 
> I
> liked the review that other members of the community did with the Swift
> proposal.

Sure - I am assuming that projects will not be operating in a vacuum,
and will be taking about the proposal long before they put to the TC.

If that needs to be called out, it should be added.

> Flavio
>

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Jeremy Stanley]

On 2016-11-08 06:43:33 -0800 (-0800), Flavio Percoco wrote:
[...]
> I think part of the community-wide concerns that were raised
> originated from the lack of an actual process for this evaluation
> to be done and the lack of up front work, which is something that
> I'm trying to address here.
[...]

Part, yes. But also a big part of it was a concern that we would
divide the community over language preferences: some only
contributing to cross-project efforts for Python-based components,
some only for Golang-based components, and neither camp
communicating with the other. This can quickly devolve into an
adversarial us-vs-them relationship, further hampering any hope for
cooperation. Maybe settling on process and tooling up-front helps
minimize this inherently social problem, but I am unconvinced.

On the other hand, I don't know that indefinitely deferring
introduction of other languages actually solves this either. If
anything, those camps will still most likely exist... just one of
them will be entirely outside the official reaches of our community
and so even more isolated and bitter.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Flavio Percoco]

On 08/11/16 16:20 +, Hayes, Graham wrote:

On 08/11/2016 15:55, Doug Hellmann wrote:

Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:

On 08/11/2016 10:30, Thierry Carrez wrote:

Ash wrote:

[...]
Here's another take on the situation. If there are people who genuinely
wish to see a CI pipeline that can support something like Go, perhaps
you can establish a prerequisite of working with the Infra team on
establishing the new pipeline. In my opinion, this seems to be the major
gate. So, if there's a clear path identified, resources provided, and
the Infra team is ultimately benefitted, then I'm not sure why there
should be another rejection. Just a thought. I know this proposal
continues to come up and I'm a big fan of seeing other languages
supported, especially Go. But I also understand that it can break
things. Personally, I would even volunteer to work on such an Infra effort.

BTW, it is quite possible that another group might feel the same
constraints. It's perfectly reasonable. But if we can overcome such
obstacles, would the TC still have a concern?


The TC isn't just one person. In complex situations like this where you
have to weigh the trade-off between opening up more choices and our
community's ability to digest/survive the change, there will always be a
wide variety of opinions. I won't claim to be able to predict how the
current membership would vote.


Yup - and the TC could possibly change half, (or even all) its members
during time it takes to get this work done.


That said, I think that if we can have more confidence that our
structure can handle it (from infra to release/stable/dep management)
and that the OpenStack community will share expertise and best practices
on Go and avoid reinventing the wheel in every project, I expect a
majority of TC members to take that leap of faith.


There was a bit of work done for the previous proposal, but the main
objections were not to do with any of points raised in this email /
blog. The objections were mainly cultural - about how it would impact
the community (which *is* very important), and the exactly why it was
needed for the projects who were asking.


To me, the important part is that introducing Go should not be another
way for some of our community to be different, but another way for our
community to be one. It should do more to bind our community together
than to split it into more factions and silos.



I would agree - but I would ask that we find a way forward that does not
require huge amounts of up front work, for a gamble at the end of the
process, where the work could be written off for any number of other
reasons.



I agree that we need to be careful about how much up-front work is
required. A plan to address some of these concerns seems like a
minimum level, with commitment to handle the immediate items like
infra resources for managing those changes. But it's hard to specify
the right levels in the abstract, because so much depends on the
situation, language, and teams involved.

Doug


This. I think trying to define objective rules, procedures, and
checklists for what is at the end of the a subjective decision is
not a great idea.

Should the policy just be "If you want to add a new language, add an
item to the TC agenda. They will the discuss the overall proposal, and
may ask for more details in the following areas, the use case, or decide
that this is not a direction that the community should proceed towards."

Or, you know, a well written version of ^.


This feels a lot like what we have today. I think the set of requirements must
be written down and clear. The evaluation of the use case should still happen
and it'd be better for it to happen before the up-front work is done. There will
always be work to do up front for any new language being added to the community.

Also, for the evaluation of the use case, it'd be awesome to have the use case
presented to the mailing list before the item is even added to the TC agenda. I
liked the review that other members of the community did with the Swift
proposal.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 15:55, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
>> On 08/11/2016 10:30, Thierry Carrez wrote:
>>> Ash wrote:
 [...]
 Here's another take on the situation. If there are people who genuinely
 wish to see a CI pipeline that can support something like Go, perhaps
 you can establish a prerequisite of working with the Infra team on
 establishing the new pipeline. In my opinion, this seems to be the major
 gate. So, if there's a clear path identified, resources provided, and
 the Infra team is ultimately benefitted, then I'm not sure why there
 should be another rejection. Just a thought. I know this proposal
 continues to come up and I'm a big fan of seeing other languages
 supported, especially Go. But I also understand that it can break
 things. Personally, I would even volunteer to work on such an Infra effort.

 BTW, it is quite possible that another group might feel the same
 constraints. It's perfectly reasonable. But if we can overcome such
 obstacles, would the TC still have a concern?
>>>
>>> The TC isn't just one person. In complex situations like this where you
>>> have to weigh the trade-off between opening up more choices and our
>>> community's ability to digest/survive the change, there will always be a
>>> wide variety of opinions. I won't claim to be able to predict how the
>>> current membership would vote.
>>
>> Yup - and the TC could possibly change half, (or even all) its members
>> during time it takes to get this work done.
>>
>>> That said, I think that if we can have more confidence that our
>>> structure can handle it (from infra to release/stable/dep management)
>>> and that the OpenStack community will share expertise and best practices
>>> on Go and avoid reinventing the wheel in every project, I expect a
>>> majority of TC members to take that leap of faith.
>>
>> There was a bit of work done for the previous proposal, but the main
>> objections were not to do with any of points raised in this email /
>> blog. The objections were mainly cultural - about how it would impact
>> the community (which *is* very important), and the exactly why it was
>> needed for the projects who were asking.
>>
>>> To me, the important part is that introducing Go should not be another
>>> way for some of our community to be different, but another way for our
>>> community to be one. It should do more to bind our community together
>>> than to split it into more factions and silos.
>>>
>>
>> I would agree - but I would ask that we find a way forward that does not
>> require huge amounts of up front work, for a gamble at the end of the
>> process, where the work could be written off for any number of other
>> reasons.
>>
>
> I agree that we need to be careful about how much up-front work is
> required. A plan to address some of these concerns seems like a
> minimum level, with commitment to handle the immediate items like
> infra resources for managing those changes. But it's hard to specify
> the right levels in the abstract, because so much depends on the
> situation, language, and teams involved.
>
> Doug

This. I think trying to define objective rules, procedures, and
checklists for what is at the end of the a subjective decision is
not a great idea.

Should the policy just be "If you want to add a new language, add an
item to the TC agenda. They will the discuss the overall proposal, and
may ask for more details in the following areas, the use case, or decide
that this is not a direction that the community should proceed towards."

Or, you know, a well written version of ^.



> __
> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-11-08 13:04:08 +:
> On 08/11/2016 10:30, Thierry Carrez wrote:
> > Ash wrote:
> >> [...]
> >> Here's another take on the situation. If there are people who genuinely
> >> wish to see a CI pipeline that can support something like Go, perhaps
> >> you can establish a prerequisite of working with the Infra team on
> >> establishing the new pipeline. In my opinion, this seems to be the major
> >> gate. So, if there's a clear path identified, resources provided, and
> >> the Infra team is ultimately benefitted, then I'm not sure why there
> >> should be another rejection. Just a thought. I know this proposal
> >> continues to come up and I'm a big fan of seeing other languages
> >> supported, especially Go. But I also understand that it can break
> >> things. Personally, I would even volunteer to work on such an Infra effort.
> >>
> >> BTW, it is quite possible that another group might feel the same
> >> constraints. It's perfectly reasonable. But if we can overcome such
> >> obstacles, would the TC still have a concern?
> >
> > The TC isn't just one person. In complex situations like this where you
> > have to weigh the trade-off between opening up more choices and our
> > community's ability to digest/survive the change, there will always be a
> > wide variety of opinions. I won't claim to be able to predict how the
> > current membership would vote.
> 
> Yup - and the TC could possibly change half, (or even all) its members
> during time it takes to get this work done.
> 
> > That said, I think that if we can have more confidence that our
> > structure can handle it (from infra to release/stable/dep management)
> > and that the OpenStack community will share expertise and best practices
> > on Go and avoid reinventing the wheel in every project, I expect a
> > majority of TC members to take that leap of faith.
> 
> There was a bit of work done for the previous proposal, but the main
> objections were not to do with any of points raised in this email /
> blog. The objections were mainly cultural - about how it would impact
> the community (which *is* very important), and the exactly why it was
> needed for the projects who were asking.
> 
> > To me, the important part is that introducing Go should not be another
> > way for some of our community to be different, but another way for our
> > community to be one. It should do more to bind our community together
> > than to split it into more factions and silos.
> >
> 
> I would agree - but I would ask that we find a way forward that does not
> require huge amounts of up front work, for a gamble at the end of the
> process, where the work could be written off for any number of other
> reasons.
> 

I agree that we need to be careful about how much up-front work is
required. A plan to address some of these concerns seems like a
minimum level, with commitment to handle the immediate items like
infra resources for managing those changes. But it's hard to specify
the right levels in the abstract, because so much depends on the
situation, language, and teams involved.

Doug

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Joshua Harlow's message of 2016-11-07 15:53:51 -0800:
> >
> > Concretely - oslo.config is important because it shapes what the config
> > files look like. The implementation language of a particular service
> > shouldn't change what our config files look like, yeah?
> 
> Standards though exist for a reason (and ini files are pretty common 
> across languages and such); though of course oslo.config has some very 
> tight integration with openstack, the underlying ini concept it 
> eventually reads/writes really isn't that special (so hopefully such a 
> thing existing isn't that hard).
> 
> As a note gflags in go (which I think is the default option mechanism?) 
> is alot like oslo.config (in fact oslo.config came from a python version 
> of gflags way back when).
> 
> Personally though I'd prefer to just say (if I could) 'ini' file is the 
> standard format for options in openstack (and drop the mix of command 
> line options and configuration/ini file options).

Yes, I wish we hadn't invented our own parser, too. That being said, we
did.

> 
> >
> > Similarly keystoneauth - not because getting a token from keystone with
> > a username and password is necessarily hard- but because we're trying to
> > drive more service-service interactions through the catalog to reduce
> > the number of things an operator needs to configure directly - and also
> > because keystone has auth plugins that need to be supported in the new
> > language too. (it's a common fault in non-python client implementations
> > that non-password auth plugins are not covered at all)
> >
> > oslo.log has similar needs - the logging for an operator needs to be
> > able to be routed to the same places and be in the same format as the
> > existing things.
> 
> Pretty sure most systems have logging that is similar to java logging 
> (which afaik is where the python logging system came from/was inspired 
> from); oslo.log has some specific tie-ins to oslo.config (but see above 
> statement of using a ini file as the option mechanism).

Which is good from a developer perspective. From a deployer perspective,
the behavior embedded in oslo.log and controlled by the config options
is what we would want to reproduce, on top of a native logging system if
possible.

> 
> >
> > oslo.messaging and oslo.db have needs where they intersect with operator
> > config.
> 
> I hope we aren't restricting ourselves to much because of the 
> specialized libraries we have made that typically have (some level) of 
> equivalent in other languages. Though of course those languages and 
> libraries do not typically(?) have the tie-together that we have created 
> with our libraries (for better or worse).
> 
> -Josh
> 

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Flavio Percoco]

On 08/11/16 13:04 +, Hayes, Graham wrote:

On 08/11/2016 10:30, Thierry Carrez wrote:

That said, I think that if we can have more confidence that our
structure can handle it (from infra to release/stable/dep management)
and that the OpenStack community will share expertise and best practices
on Go and avoid reinventing the wheel in every project, I expect a
majority of TC members to take that leap of faith.


There was a bit of work done for the previous proposal, but the main
objections were not to do with any of points raised in this email /
blog. The objections were mainly cultural - about how it would impact
the community (which *is* very important), and the exactly why it was
needed for the projects who were asking.


I think part of the community-wide concerns that were raised originated from the
lack of an actual process for this evaluation to be done and the lack of up
front work, which is something that I'm trying to address here. This is a new
process and I think defining this expectations is the key to help with future
proposals.

I believe an early evaluation of the needs for a new language should still be
part of the process, though. Likely at the very beginning of the process, before
the up front work is even started.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 08/11/2016 10:30, Thierry Carrez wrote:
> Ash wrote:
>> [...]
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps
>> you can establish a prerequisite of working with the Infra team on
>> establishing the new pipeline. In my opinion, this seems to be the major
>> gate. So, if there's a clear path identified, resources provided, and
>> the Infra team is ultimately benefitted, then I'm not sure why there
>> should be another rejection. Just a thought. I know this proposal
>> continues to come up and I'm a big fan of seeing other languages
>> supported, especially Go. But I also understand that it can break
>> things. Personally, I would even volunteer to work on such an Infra effort.
>>
>> BTW, it is quite possible that another group might feel the same
>> constraints. It's perfectly reasonable. But if we can overcome such
>> obstacles, would the TC still have a concern?
>
> The TC isn't just one person. In complex situations like this where you
> have to weigh the trade-off between opening up more choices and our
> community's ability to digest/survive the change, there will always be a
> wide variety of opinions. I won't claim to be able to predict how the
> current membership would vote.

Yup - and the TC could possibly change half, (or even all) its members
during time it takes to get this work done.

> That said, I think that if we can have more confidence that our
> structure can handle it (from infra to release/stable/dep management)
> and that the OpenStack community will share expertise and best practices
> on Go and avoid reinventing the wheel in every project, I expect a
> majority of TC members to take that leap of faith.

There was a bit of work done for the previous proposal, but the main
objections were not to do with any of points raised in this email /
blog. The objections were mainly cultural - about how it would impact
the community (which *is* very important), and the exactly why it was
needed for the projects who were asking.

> To me, the important part is that introducing Go should not be another
> way for some of our community to be different, but another way for our
> community to be one. It should do more to bind our community together
> than to split it into more factions and silos.
>

I would agree - but I would ask that we find a way forward that does not
require huge amounts of up front work, for a gamble at the end of the
process, where the work could be written off for any number of other
reasons.

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Thierry Carrez]

Ash wrote:
> [...]
> Here's another take on the situation. If there are people who genuinely
> wish to see a CI pipeline that can support something like Go, perhaps
> you can establish a prerequisite of working with the Infra team on
> establishing the new pipeline. In my opinion, this seems to be the major
> gate. So, if there's a clear path identified, resources provided, and
> the Infra team is ultimately benefitted, then I'm not sure why there
> should be another rejection. Just a thought. I know this proposal
> continues to come up and I'm a big fan of seeing other languages
> supported, especially Go. But I also understand that it can break
> things. Personally, I would even volunteer to work on such an Infra effort. 
> 
> BTW, it is quite possible that another group might feel the same
> constraints. It's perfectly reasonable. But if we can overcome such
> obstacles, would the TC still have a concern? 

The TC isn't just one person. In complex situations like this where you
have to weigh the trade-off between opening up more choices and our
community's ability to digest/survive the change, there will always be a
wide variety of opinions. I won't claim to be able to predict how the
current membership would vote.

That said, I think that if we can have more confidence that our
structure can handle it (from infra to release/stable/dep management)
and that the OpenStack community will share expertise and best practices
on Go and avoid reinventing the wheel in every project, I expect a
majority of TC members to take that leap of faith.

To me, the important part is that introducing Go should not be another
way for some of our community to be different, but another way for our
community to be one. It should do more to bind our community together
than to split it into more factions and silos.

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Ashlee Young]

Thanks, Jeremy! I don't expect much hand holding but am trying to come up to 
speed.

Sent from my iPhone

> On Nov 7, 2016, at 11:10, Jeremy Stanley  wrote:
> 
>> On 2016-11-07 10:31:22 -0800 (-0800), Ash wrote:
>> [...]
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps you
>> can establish a prerequisite of working with the Infra team on establishing
>> the new pipeline. In my opinion, this seems to be the major gate. So, if
>> there's a clear path identified, resources provided, and the Infra team is
>> ultimately benefitted, then I'm not sure why there should be another
>> rejection. Just a thought. I know this proposal continues to come up and
>> I'm a big fan of seeing other languages supported, especially Go. But I
>> also understand that it can break things. Personally, I would even
>> volunteer to work on such an Infra effort.
> [...]
> 
> Welcome aboard! Monty's already laid some of the groundwork, but
> really most of the effort is just getting familiar with what we
> already have and how to avoid duplicating work. As has been pointed
> out we're spread pretty thin, but not so thin that we can't answer
> questions posed by someone who is driven and relatively
> self-sufficient reading documentation and looking at production
> examples. Most of the solutions implemented in our infrastructure
> come from interested members of the community at large, and we're
> proud of our ability to enable that sort of inclusive participation.
> 
> I won't pretend it isn't complex and don't expect members of the
> Infra team to have sufficient bandwidth for hand-holding and
> spoon-feeding, but we do our best to help guide contributors toward
> implementing solutions that benefit the community at large. Even if
> Go isn't a TC-sanctioned language for official OpenStack
> deliverables, having the ability to support it (or Haskel, or Ada,
> or...) in our community infrastructure eases experimentation and
> promotes language-specific innovation for unofficial repositories
> within our ecosystem.
> -- 
> Jeremy Stanley
> __
> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Joshua Harlow]

Concretely - oslo.config is important because it shapes what the config
files look like. The implementation language of a particular service
shouldn't change what our config files look like, yeah?


Standards though exist for a reason (and ini files are pretty common 
across languages and such); though of course oslo.config has some very 
tight integration with openstack, the underlying ini concept it 
eventually reads/writes really isn't that special (so hopefully such a 
thing existing isn't that hard).


As a note gflags in go (which I think is the default option mechanism?) 
is alot like oslo.config (in fact oslo.config came from a python version 
of gflags way back when).


Personally though I'd prefer to just say (if I could) 'ini' file is the 
standard format for options in openstack (and drop the mix of command 
line options and configuration/ini file options).




Similarly keystoneauth - not because getting a token from keystone with
a username and password is necessarily hard- but because we're trying to
drive more service-service interactions through the catalog to reduce
the number of things an operator needs to configure directly - and also
because keystone has auth plugins that need to be supported in the new
language too. (it's a common fault in non-python client implementations
that non-password auth plugins are not covered at all)

oslo.log has similar needs - the logging for an operator needs to be
able to be routed to the same places and be in the same format as the
existing things.


Pretty sure most systems have logging that is similar to java logging 
(which afaik is where the python logging system came from/was inspired 
from); oslo.log has some specific tie-ins to oslo.config (but see above 
statement of using a ini file as the option mechanism).




oslo.messaging and oslo.db have needs where they intersect with operator
config.


I hope we aren't restricting ourselves to much because of the 
specialized libraries we have made that typically have (some level) of 
equivalent in other languages. Though of course those languages and 
libraries do not typically(?) have the tie-together that we have created 
with our libraries (for better or worse).


-Josh

__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Dean Troyer]

On Mon, Nov 7, 2016 at 1:32 PM, Flavio Percoco  wrote:
> I agree with Monty here. If I were to "prioritize" the work on these
> libraries,
> I'd say parity on the operator's side of things should be the priority. The
> rest
> of the libraries could be implemented as they are needed.
>
> I don't think they all need to be implemented but I do think some of them
> should, especially because I believe the process of adding a new language
> should
> also involve building the ecosystem within the openstack community for that
> language to exist and be consumed.
>
> Wether this should be a hard requirement or not is something that we can
> talk
> more about. What I would like to avoid is a scenario were the service/team
> requesting the addition of the language doesn't use any of the common tools
> that
> exist today and we end up adding a new language and dropping all the work on
> compatibility to teams coming after. I believe this is exactly the scenario
> that
> we're in right now.

I agree with the overall concern, however I'm looking at it
(specifically the Swift Hummingbird proposal from May) as a step to
get there without biting off the entire chunk at once.  The infra
work, the community work, the packaging all is enough to handle at
once, this particular situation doesn't require oslo(-like) libraries
to gain benefit of work we need to do anyway.

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Doug Hellmann]

Excerpts from Flavio Percoco's message of 2016-11-07 11:32:06 -0800:
> On 07/11/16 12:16 -0600, Monty Taylor wrote:
> >On 11/07/2016 11:58 AM, Hayes, Graham wrote:
> >> On 07/11/2016 17:14, Flavio Percoco wrote:
> >>> Greetings,
> >>>
> >>> I literally just posted a thing on my blog with some thoughts of what I'd 
> >>> expect
> >>> any new language being proposed for OpenStack to cover before it can be
> >>> accepted.
> >>>
> >>> The goal is to set the expectations right for what's needed for new 
> >>> languages to
> >>> be accepted in the community. During the last evaluation of the Go 
> >>> proposal I
> >>> raised some concerns but I also said I was not closed to discussing this 
> >>> again
> >>> in the future. It's clear we've not documented expectations yet and this 
> >>> is a
> >>> first step to get that going before a new proposal comes up and we start
> >>> discussing this topic again.
> >>>
> >>> I don't think a blog post is the "way we should do this" but it was my 
> >>> way to
> >>> dump what's in my brain before working on something official (which I'll 
> >>> do
> >>> this/next week).
> >>>
> >>> I also don't think this list is perfect. It could either be too 
> >>> restrictive or
> >>> too open but it's a first step. I won't paste the content of my post in 
> >>> this
> >>> email but I'll provide a tl;dr and eventually come back with the actual
> >>> reference document patch. I thought I'd drop this here in case people 
> >>> read my
> >>> post and were confused about what's going on there.
> >>>
> >>> Ok, here's the TL;DR of what I believe we should know/do before accepting 
> >>> a new
> >>> language into the community:
> >>
> >> Its a great starting point, but there is one issue:
> >>
> >> This is a *huge* amount of work to get into place, for the TC to still
> >> potentially refuse the language. (I know you covered this in your blog
> >> post, but I think there is a level of underestimation there.)
> >
> >Yes, it is absolutely a huge amount of work for sure, and I think your
> >point is important.
> >
> >>
> >>> - Define a way to share code/libraries for projects using the language
> >>
> >> ++ - Definitely needed
> >>
> >>> - Work on a basic set of libraries for OpenStack base services
> >>
> >> What do we include here? You called out these:
> >>
> >> keystoneauth / keystone-client
> >> oslo.config
> >> oslo.db
> >> oslo.messaging
> >>
> >> We need to also include
> >>
> >> oslo.log
> >>
> >> Do they *all* need to be implemented? Just some? Do they need feature
> >> parity?
> >
> >To me the most important piece is feature parity on the operator
> >interaction side.
> >
> >Concretely - oslo.config is important because it shapes what the config
> >files look like. The implementation language of a particular service
> >shouldn't change what our config files look like, yeah?
> >
> >Similarly keystoneauth - not because getting a token from keystone with
> >a username and password is necessarily hard- but because we're trying to
> >drive more service-service interactions through the catalog to reduce
> >the number of things an operator needs to configure directly - and also
> >because keystone has auth plugins that need to be supported in the new
> >language too. (it's a common fault in non-python client implementations
> >that non-password auth plugins are not covered at all)
> >
> >oslo.log has similar needs - the logging for an operator needs to be
> >able to be routed to the same places and be in the same format as the
> >existing things.
> >
> >oslo.messaging and oslo.db have needs where they intersect with operator
> >config.
> 
> 
> I agree with Monty here. If I were to "prioritize" the work on these 
> libraries,
> I'd say parity on the operator's side of things should be the priority. The 
> rest
> of the libraries could be implemented as they are needed.
> 
> I don't think they all need to be implemented but I do think some of them
> should, especially because I believe the process of adding a new language 
> should
> also involve building the ecosystem within the openstack community for that
> language to exist and be consumed.
> 
> Wether this should be a hard requirement or not is something that we can talk
> more about. What I would like to avoid is a scenario were the service/team
> requesting the addition of the language doesn't use any of the common tools 
> that
> exist today and we end up adding a new language and dropping all the work on
> compatibility to teams coming after. I believe this is exactly the scenario 
> that
> we're in right now.

Right. It's much more important to me that a system be put in place
to produce and manage the libraries than that they are created in
any particular order. Oslo came after Swift and Nova, but we've
learned that building shared libraries is an important part of our
community's answer to the call for consistency that needs to extend
to new languages from the beginning of their adoption.

> >> For example the previous discussion 

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Flavio Percoco]

On 07/11/16 12:16 -0600, Monty Taylor wrote:

On 11/07/2016 11:58 AM, Hayes, Graham wrote:

On 07/11/2016 17:14, Flavio Percoco wrote:

Greetings,

I literally just posted a thing on my blog with some thoughts of what I'd expect
any new language being proposed for OpenStack to cover before it can be
accepted.

The goal is to set the expectations right for what's needed for new languages to
be accepted in the community. During the last evaluation of the Go proposal I
raised some concerns but I also said I was not closed to discussing this again
in the future. It's clear we've not documented expectations yet and this is a
first step to get that going before a new proposal comes up and we start
discussing this topic again.

I don't think a blog post is the "way we should do this" but it was my way to
dump what's in my brain before working on something official (which I'll do
this/next week).

I also don't think this list is perfect. It could either be too restrictive or
too open but it's a first step. I won't paste the content of my post in this
email but I'll provide a tl;dr and eventually come back with the actual
reference document patch. I thought I'd drop this here in case people read my
post and were confused about what's going on there.

Ok, here's the TL;DR of what I believe we should know/do before accepting a new
language into the community:


Its a great starting point, but there is one issue:

This is a *huge* amount of work to get into place, for the TC to still
potentially refuse the language. (I know you covered this in your blog
post, but I think there is a level of underestimation there.)


Yes, it is absolutely a huge amount of work for sure, and I think your
point is important.




- Define a way to share code/libraries for projects using the language


++ - Definitely needed


- Work on a basic set of libraries for OpenStack base services


What do we include here? You called out these:

keystoneauth / keystone-client
oslo.config
oslo.db
oslo.messaging

We need to also include

oslo.log

Do they *all* need to be implemented? Just some? Do they need feature
parity?


To me the most important piece is feature parity on the operator
interaction side.

Concretely - oslo.config is important because it shapes what the config
files look like. The implementation language of a particular service
shouldn't change what our config files look like, yeah?

Similarly keystoneauth - not because getting a token from keystone with
a username and password is necessarily hard- but because we're trying to
drive more service-service interactions through the catalog to reduce
the number of things an operator needs to configure directly - and also
because keystone has auth plugins that need to be supported in the new
language too. (it's a common fault in non-python client implementations
that non-password auth plugins are not covered at all)

oslo.log has similar needs - the logging for an operator needs to be
able to be routed to the same places and be in the same format as the
existing things.

oslo.messaging and oslo.db have needs where they intersect with operator
config.



I agree with Monty here. If I were to "prioritize" the work on these libraries,
I'd say parity on the operator's side of things should be the priority. The rest
of the libraries could be implemented as they are needed.

I don't think they all need to be implemented but I do think some of them
should, especially because I believe the process of adding a new language should
also involve building the ecosystem within the openstack community for that
language to exist and be consumed.

Wether this should be a hard requirement or not is something that we can talk
more about. What I would like to avoid is a scenario were the service/team
requesting the addition of the language doesn't use any of the common tools that
exist today and we end up adding a new language and dropping all the work on
compatibility to teams coming after. I believe this is exactly the scenario that
we're in right now.


For example the previous discussion about Go had 2 components that would
have required at most 2 of these base libraries (and I think that was
mainly on the Designate side - the swift implementation did not need
any (I think - I am open to correction)


- Define how the deliverables are distributed


++ - but this needs to be done with the release management teams input.
What I think is reasonable may not be something that they are interested
in supporting.


Absolutely. I mentioned in the post that working with the release team is key
for this.


- Define how stable maintenance will work


++


- Setup the CI pipelines for the new language


This requires the -infra team dedicate (what are already stretched)
resources to a theoretical situation, doing work that may be thrown
away if the TC rejects a language.



Ditto... Regardless of how swamped the infra team is, I believe this requires
working with them. Actually, I don't see the infra team being 

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Monty Taylor]

On 11/07/2016 12:51 PM, John Dickinson wrote:
> 
> 
> On 7 Nov 2016, at 10:31, Ash wrote:
> 
>> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham  wrote:
>>
>>> On 07/11/2016 17:14, Flavio Percoco wrote:
 Greetings,

 I literally just posted a thing on my blog with some thoughts of what
>>> I'd expect
 any new language being proposed for OpenStack to cover before it can be
 accepted.

 The goal is to set the expectations right for what's needed for new
>>> languages to
 be accepted in the community. During the last evaluation of the Go
>>> proposal I
 raised some concerns but I also said I was not closed to discussing this
>>> again
 in the future. It's clear we've not documented expectations yet and this
>>> is a
 first step to get that going before a new proposal comes up and we start
 discussing this topic again.

 I don't think a blog post is the "way we should do this" but it was my
>>> way to
 dump what's in my brain before working on something official (which I'll
>>> do
 this/next week).

 I also don't think this list is perfect. It could either be too
>>> restrictive or
 too open but it's a first step. I won't paste the content of my post in
>>> this
 email but I'll provide a tl;dr and eventually come back with the actual
 reference document patch. I thought I'd drop this here in case people
>>> read my
 post and were confused about what's going on there.

 Ok, here's the TL;DR of what I believe we should know/do before
>>> accepting a new
 language into the community:
>>>
>>> Its a great starting point, but there is one issue:
>>>
>>> This is a *huge* amount of work to get into place, for the TC to still
>>> potentially refuse the language. (I know you covered this in your blog
>>> post, but I think there is a level of underestimation there.)
>>>
>>>
 - Define a way to share code/libraries for projects using the language
>>>
>>> ++ - Definitely needed
>>>
 - Work on a basic set of libraries for OpenStack base services
>>>
>>> What do we include here? You called out these:
>>>
>>> keystoneauth / keystone-client
>>> oslo.config
>>> oslo.db
>>> oslo.messaging
>>>
>>> We need to also include
>>>
>>> oslo.log
>>>
>>> Do they *all* need to be implemented? Just some? Do they need feature
>>> parity?
>>>
>>> For example the previous discussion about Go had 2 components that would
>>> have required at most 2 of these base libraries (and I think that was
>>> mainly on the Designate side - the swift implementation did not need
>>> any (I think - I am open to correction)
>>>
 - Define how the deliverables are distributed
>>>
>>> ++ - but this needs to be done with the release management teams input.
>>> What I think is reasonable may not be something that they are interested
>>> in supporting.
>>>
 - Define how stable maintenance will work
>>>
>>> ++
>>>
 - Setup the CI pipelines for the new language
>>>
>>> This requires the -infra team dedicate (what are already stretched)
>>> resources to a theoretical situation, doing work that may be thrown
>>> away if the TC rejects a language.
>>>
>> Here's another take on the situation. If there are people who genuinely
>> wish to see a CI pipeline that can support something like Go, perhaps you
>> can establish a prerequisite of working with the Infra team on establishing
>> the new pipeline. In my opinion, this seems to be the major gate. So, if
>> there's a clear path identified, resources provided, and the Infra team is
>> ultimately benefitted, then I'm not sure why there should be another
>> rejection. Just a thought. I know this proposal continues to come up and
>> I'm a big fan of seeing other languages supported, especially Go. But I
>> also understand that it can break things. Personally, I would even
>> volunteer to work on such an Infra effort.
>>
>> BTW, it is quite possible that another group might feel the same
>> constraints. It's perfectly reasonable. But if we can overcome such
>> obstacles, would the TC still have a concern?
> 
> 
> Here's the notes we had from last May when we started the Golang discussion 
> where we started working through these questions.
> 
> https://etherpad.openstack.org/p/golang-infra-issues-to-solve

I've just added a few more notes to it - turns out time has elapsed
since last May. :)

>>>
>>> I foresee these requirements as a whole being overly onerous, and
>>> having the same result as saying "no new languages".
>>>
>>> I think that there should be base research into all of these, but the
>>> requirements for some of these to be fully completed could be basically
>>> impossible.
>>>

 The longer and more detailed version is here:

 https://blog.flaper87.com/embracing-other-languages-openstack.html

 Stay tuned,
 Flavio

>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for 

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Jeremy Stanley]

On 2016-11-07 10:31:22 -0800 (-0800), Ash wrote:
[...]
> Here's another take on the situation. If there are people who genuinely
> wish to see a CI pipeline that can support something like Go, perhaps you
> can establish a prerequisite of working with the Infra team on establishing
> the new pipeline. In my opinion, this seems to be the major gate. So, if
> there's a clear path identified, resources provided, and the Infra team is
> ultimately benefitted, then I'm not sure why there should be another
> rejection. Just a thought. I know this proposal continues to come up and
> I'm a big fan of seeing other languages supported, especially Go. But I
> also understand that it can break things. Personally, I would even
> volunteer to work on such an Infra effort.
[...]

Welcome aboard! Monty's already laid some of the groundwork, but
really most of the effort is just getting familiar with what we
already have and how to avoid duplicating work. As has been pointed
out we're spread pretty thin, but not so thin that we can't answer
questions posed by someone who is driven and relatively
self-sufficient reading documentation and looking at production
examples. Most of the solutions implemented in our infrastructure
come from interested members of the community at large, and we're
proud of our ability to enable that sort of inclusive participation.

I won't pretend it isn't complex and don't expect members of the
Infra team to have sufficient bandwidth for hand-holding and
spoon-feeding, but we do our best to help guide contributors toward
implementing solutions that benefit the community at large. Even if
Go isn't a TC-sanctioned language for official OpenStack
deliverables, having the ability to support it (or Haskel, or Ada,
or...) in our community infrastructure eases experimentation and
promotes language-specific innovation for unofficial repositories
within our ecosystem.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[John Dickinson]

On 7 Nov 2016, at 10:31, Ash wrote:

> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham  wrote:
>
>> On 07/11/2016 17:14, Flavio Percoco wrote:
>>> Greetings,
>>>
>>> I literally just posted a thing on my blog with some thoughts of what
>> I'd expect
>>> any new language being proposed for OpenStack to cover before it can be
>>> accepted.
>>>
>>> The goal is to set the expectations right for what's needed for new
>> languages to
>>> be accepted in the community. During the last evaluation of the Go
>> proposal I
>>> raised some concerns but I also said I was not closed to discussing this
>> again
>>> in the future. It's clear we've not documented expectations yet and this
>> is a
>>> first step to get that going before a new proposal comes up and we start
>>> discussing this topic again.
>>>
>>> I don't think a blog post is the "way we should do this" but it was my
>> way to
>>> dump what's in my brain before working on something official (which I'll
>> do
>>> this/next week).
>>>
>>> I also don't think this list is perfect. It could either be too
>> restrictive or
>>> too open but it's a first step. I won't paste the content of my post in
>> this
>>> email but I'll provide a tl;dr and eventually come back with the actual
>>> reference document patch. I thought I'd drop this here in case people
>> read my
>>> post and were confused about what's going on there.
>>>
>>> Ok, here's the TL;DR of what I believe we should know/do before
>> accepting a new
>>> language into the community:
>>
>> Its a great starting point, but there is one issue:
>>
>> This is a *huge* amount of work to get into place, for the TC to still
>> potentially refuse the language. (I know you covered this in your blog
>> post, but I think there is a level of underestimation there.)
>>
>>
>>> - Define a way to share code/libraries for projects using the language
>>
>> ++ - Definitely needed
>>
>>> - Work on a basic set of libraries for OpenStack base services
>>
>> What do we include here? You called out these:
>>
>> keystoneauth / keystone-client
>> oslo.config
>> oslo.db
>> oslo.messaging
>>
>> We need to also include
>>
>> oslo.log
>>
>> Do they *all* need to be implemented? Just some? Do they need feature
>> parity?
>>
>> For example the previous discussion about Go had 2 components that would
>> have required at most 2 of these base libraries (and I think that was
>> mainly on the Designate side - the swift implementation did not need
>> any (I think - I am open to correction)
>>
>>> - Define how the deliverables are distributed
>>
>> ++ - but this needs to be done with the release management teams input.
>> What I think is reasonable may not be something that they are interested
>> in supporting.
>>
>>> - Define how stable maintenance will work
>>
>> ++
>>
>>> - Setup the CI pipelines for the new language
>>
>> This requires the -infra team dedicate (what are already stretched)
>> resources to a theoretical situation, doing work that may be thrown
>> away if the TC rejects a language.
>>
> Here's another take on the situation. If there are people who genuinely
> wish to see a CI pipeline that can support something like Go, perhaps you
> can establish a prerequisite of working with the Infra team on establishing
> the new pipeline. In my opinion, this seems to be the major gate. So, if
> there's a clear path identified, resources provided, and the Infra team is
> ultimately benefitted, then I'm not sure why there should be another
> rejection. Just a thought. I know this proposal continues to come up and
> I'm a big fan of seeing other languages supported, especially Go. But I
> also understand that it can break things. Personally, I would even
> volunteer to work on such an Infra effort.
>
> BTW, it is quite possible that another group might feel the same
> constraints. It's perfectly reasonable. But if we can overcome such
> obstacles, would the TC still have a concern?


Here's the notes we had from last May when we started the Golang discussion 
where we started working through these questions.

https://etherpad.openstack.org/p/golang-infra-issues-to-solve


>
>>
>> I foresee these requirements as a whole being overly onerous, and
>> having the same result as saying "no new languages".
>>
>> I think that there should be base research into all of these, but the
>> requirements for some of these to be fully completed could be basically
>> impossible.
>>
>>>
>>> The longer and more detailed version is here:
>>>
>>> https://blog.flaper87.com/embracing-other-languages-openstack.html
>>>
>>> Stay tuned,
>>> Flavio
>>>
>>
>>
>> __
>> 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 

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Ash]

On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham  wrote:

> On 07/11/2016 17:14, Flavio Percoco wrote:
> > Greetings,
> >
> > I literally just posted a thing on my blog with some thoughts of what
> I'd expect
> > any new language being proposed for OpenStack to cover before it can be
> > accepted.
> >
> > The goal is to set the expectations right for what's needed for new
> languages to
> > be accepted in the community. During the last evaluation of the Go
> proposal I
> > raised some concerns but I also said I was not closed to discussing this
> again
> > in the future. It's clear we've not documented expectations yet and this
> is a
> > first step to get that going before a new proposal comes up and we start
> > discussing this topic again.
> >
> > I don't think a blog post is the "way we should do this" but it was my
> way to
> > dump what's in my brain before working on something official (which I'll
> do
> > this/next week).
> >
> > I also don't think this list is perfect. It could either be too
> restrictive or
> > too open but it's a first step. I won't paste the content of my post in
> this
> > email but I'll provide a tl;dr and eventually come back with the actual
> > reference document patch. I thought I'd drop this here in case people
> read my
> > post and were confused about what's going on there.
> >
> > Ok, here's the TL;DR of what I believe we should know/do before
> accepting a new
> > language into the community:
>
> Its a great starting point, but there is one issue:
>
> This is a *huge* amount of work to get into place, for the TC to still
> potentially refuse the language. (I know you covered this in your blog
> post, but I think there is a level of underestimation there.)
>
>
> > - Define a way to share code/libraries for projects using the language
>
> ++ - Definitely needed
>
> > - Work on a basic set of libraries for OpenStack base services
>
> What do we include here? You called out these:
>
> keystoneauth / keystone-client
> oslo.config
> oslo.db
> oslo.messaging
>
> We need to also include
>
> oslo.log
>
> Do they *all* need to be implemented? Just some? Do they need feature
> parity?
>
> For example the previous discussion about Go had 2 components that would
> have required at most 2 of these base libraries (and I think that was
> mainly on the Designate side - the swift implementation did not need
> any (I think - I am open to correction)
>
> > - Define how the deliverables are distributed
>
> ++ - but this needs to be done with the release management teams input.
> What I think is reasonable may not be something that they are interested
> in supporting.
>
> > - Define how stable maintenance will work
>
> ++
>
> > - Setup the CI pipelines for the new language
>
> This requires the -infra team dedicate (what are already stretched)
> resources to a theoretical situation, doing work that may be thrown
> away if the TC rejects a language.
>
Here's another take on the situation. If there are people who genuinely
wish to see a CI pipeline that can support something like Go, perhaps you
can establish a prerequisite of working with the Infra team on establishing
the new pipeline. In my opinion, this seems to be the major gate. So, if
there's a clear path identified, resources provided, and the Infra team is
ultimately benefitted, then I'm not sure why there should be another
rejection. Just a thought. I know this proposal continues to come up and
I'm a big fan of seeing other languages supported, especially Go. But I
also understand that it can break things. Personally, I would even
volunteer to work on such an Infra effort.

BTW, it is quite possible that another group might feel the same
constraints. It's perfectly reasonable. But if we can overcome such
obstacles, would the TC still have a concern?

>
> I foresee these requirements as a whole being overly onerous, and
> having the same result as saying "no new languages".
>
> I think that there should be base research into all of these, but the
> requirements for some of these to be fully completed could be basically
> impossible.
>
> >
> > The longer and more detailed version is here:
> >
> > https://blog.flaper87.com/embracing-other-languages-openstack.html
> >
> > Stay tuned,
> > Flavio
> >
>
>
> __
> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Monty Taylor]

On 11/07/2016 11:58 AM, Hayes, Graham wrote:
> On 07/11/2016 17:14, Flavio Percoco wrote:
>> Greetings,
>>
>> I literally just posted a thing on my blog with some thoughts of what I'd 
>> expect
>> any new language being proposed for OpenStack to cover before it can be
>> accepted.
>>
>> The goal is to set the expectations right for what's needed for new 
>> languages to
>> be accepted in the community. During the last evaluation of the Go proposal I
>> raised some concerns but I also said I was not closed to discussing this 
>> again
>> in the future. It's clear we've not documented expectations yet and this is a
>> first step to get that going before a new proposal comes up and we start
>> discussing this topic again.
>>
>> I don't think a blog post is the "way we should do this" but it was my way to
>> dump what's in my brain before working on something official (which I'll do
>> this/next week).
>>
>> I also don't think this list is perfect. It could either be too restrictive 
>> or
>> too open but it's a first step. I won't paste the content of my post in this
>> email but I'll provide a tl;dr and eventually come back with the actual
>> reference document patch. I thought I'd drop this here in case people read my
>> post and were confused about what's going on there.
>>
>> Ok, here's the TL;DR of what I believe we should know/do before accepting a 
>> new
>> language into the community:
> 
> Its a great starting point, but there is one issue:
> 
> This is a *huge* amount of work to get into place, for the TC to still
> potentially refuse the language. (I know you covered this in your blog
> post, but I think there is a level of underestimation there.)

Yes, it is absolutely a huge amount of work for sure, and I think your
point is important.

> 
>> - Define a way to share code/libraries for projects using the language
> 
> ++ - Definitely needed
> 
>> - Work on a basic set of libraries for OpenStack base services
> 
> What do we include here? You called out these:
> 
> keystoneauth / keystone-client
> oslo.config
> oslo.db
> oslo.messaging
> 
> We need to also include
> 
> oslo.log
> 
> Do they *all* need to be implemented? Just some? Do they need feature
> parity?

To me the most important piece is feature parity on the operator
interaction side.

Concretely - oslo.config is important because it shapes what the config
files look like. The implementation language of a particular service
shouldn't change what our config files look like, yeah?

Similarly keystoneauth - not because getting a token from keystone with
a username and password is necessarily hard- but because we're trying to
drive more service-service interactions through the catalog to reduce
the number of things an operator needs to configure directly - and also
because keystone has auth plugins that need to be supported in the new
language too. (it's a common fault in non-python client implementations
that non-password auth plugins are not covered at all)

oslo.log has similar needs - the logging for an operator needs to be
able to be routed to the same places and be in the same format as the
existing things.

oslo.messaging and oslo.db have needs where they intersect with operator
config.

> For example the previous discussion about Go had 2 components that would
> have required at most 2 of these base libraries (and I think that was
> mainly on the Designate side - the swift implementation did not need
> any (I think - I am open to correction)
> 
>> - Define how the deliverables are distributed
> 
> ++ - but this needs to be done with the release management teams input.
> What I think is reasonable may not be something that they are interested
> in supporting.
> 
>> - Define how stable maintenance will work
> 
> ++
> 
>> - Setup the CI pipelines for the new language
> 
> This requires the -infra team dedicate (what are already stretched)
> resources to a theoretical situation, doing work that may be thrown
> away if the TC rejects a language.
> 
> I foresee these requirements as a whole being overly onerous, and
> having the same result as saying "no new languages".
> 
> I think that there should be base research into all of these, but the
> requirements for some of these to be fully completed could be basically
> impossible.

Having a solution for deliverable distribution, stable maintenance,
shared requirements management and caching/mirroring for the gate are
things I personally think are pre-requisites. They're conceptually hard
but not necessarily a giant amount of hands-on-ground work. (some work,
but not an excessive amount) They represent the parts of the
intra-developer social contract that exists within the structures of how
we operate on repositories.

I would think that library coverage needs a plan, but doesn't need to be
_finished_ - until such a time as the deliverable in question needs to
be delivered. Or, put another way - we need to have a clear list of
things and a mechanism for doing them - but we don't need a 

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Hayes, Graham]

On 07/11/2016 17:14, Flavio Percoco wrote:
> Greetings,
>
> I literally just posted a thing on my blog with some thoughts of what I'd 
> expect
> any new language being proposed for OpenStack to cover before it can be
> accepted.
>
> The goal is to set the expectations right for what's needed for new languages 
> to
> be accepted in the community. During the last evaluation of the Go proposal I
> raised some concerns but I also said I was not closed to discussing this again
> in the future. It's clear we've not documented expectations yet and this is a
> first step to get that going before a new proposal comes up and we start
> discussing this topic again.
>
> I don't think a blog post is the "way we should do this" but it was my way to
> dump what's in my brain before working on something official (which I'll do
> this/next week).
>
> I also don't think this list is perfect. It could either be too restrictive or
> too open but it's a first step. I won't paste the content of my post in this
> email but I'll provide a tl;dr and eventually come back with the actual
> reference document patch. I thought I'd drop this here in case people read my
> post and were confused about what's going on there.
>
> Ok, here's the TL;DR of what I believe we should know/do before accepting a 
> new
> language into the community:

Its a great starting point, but there is one issue:

This is a *huge* amount of work to get into place, for the TC to still
potentially refuse the language. (I know you covered this in your blog
post, but I think there is a level of underestimation there.)


> - Define a way to share code/libraries for projects using the language

++ - Definitely needed

> - Work on a basic set of libraries for OpenStack base services

What do we include here? You called out these:

keystoneauth / keystone-client
oslo.config
oslo.db
oslo.messaging

We need to also include

oslo.log

Do they *all* need to be implemented? Just some? Do they need feature
parity?

For example the previous discussion about Go had 2 components that would
have required at most 2 of these base libraries (and I think that was
mainly on the Designate side - the swift implementation did not need
any (I think - I am open to correction)

> - Define how the deliverables are distributed

++ - but this needs to be done with the release management teams input.
What I think is reasonable may not be something that they are interested
in supporting.

> - Define how stable maintenance will work

++

> - Setup the CI pipelines for the new language

This requires the -infra team dedicate (what are already stretched)
resources to a theoretical situation, doing work that may be thrown
away if the TC rejects a language.

I foresee these requirements as a whole being overly onerous, and
having the same result as saying "no new languages".

I think that there should be base research into all of these, but the
requirements for some of these to be fully completed could be basically
impossible.

>
> The longer and more detailed version is here:
>
> https://blog.flaper87.com/embracing-other-languages-openstack.html
>
> Stay tuned,
> Flavio
>


__
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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

[Jordan Pittier]

Again ? Are we going to have that discussion every 3 months... ?

On Mon, Nov 7, 2016 at 6:09 PM, Flavio Percoco  wrote:

> Greetings,
>
> I literally just posted a thing on my blog with some thoughts of what I'd
> expect
> any new language being proposed for OpenStack to cover before it can be
> accepted.
>
> The goal is to set the expectations right for what's needed for new
> languages to
> be accepted in the community. During the last evaluation of the Go
> proposal I
> raised some concerns but I also said I was not closed to discussing this
> again
> in the future. It's clear we've not documented expectations yet and this
> is a
> first step to get that going before a new proposal comes up and we start
> discussing this topic again.
>
> I don't think a blog post is the "way we should do this" but it was my way
> to
> dump what's in my brain before working on something official (which I'll do
> this/next week).
>
> I also don't think this list is perfect. It could either be too
> restrictive or
> too open but it's a first step. I won't paste the content of my post in
> this
> email but I'll provide a tl;dr and eventually come back with the actual
> reference document patch. I thought I'd drop this here in case people read
> my
> post and were confused about what's going on there.
>
> Ok, here's the TL;DR of what I believe we should know/do before accepting
> a new
> language into the community:
>
> - Define a way to share code/libraries for projects using the language
> - Work on a basic set of libraries for OpenStack base services
> - Define how the deliverables are distributed
> - Define how stable maintenance will work
> - Setup the CI pipelines for the new language
>
> The longer and more detailed version is here:
>
> https://blog.flaper87.com/embracing-other-languages-openstack.html
>
> Stay tuned,
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Embracing new languages in OpenStack

[Flavio Percoco]

Greetings,

I literally just posted a thing on my blog with some thoughts of what I'd expect
any new language being proposed for OpenStack to cover before it can be
accepted.

The goal is to set the expectations right for what's needed for new languages to
be accepted in the community. During the last evaluation of the Go proposal I
raised some concerns but I also said I was not closed to discussing this again
in the future. It's clear we've not documented expectations yet and this is a
first step to get that going before a new proposal comes up and we start
discussing this topic again.

I don't think a blog post is the "way we should do this" but it was my way to
dump what's in my brain before working on something official (which I'll do
this/next week).

I also don't think this list is perfect. It could either be too restrictive or
too open but it's a first step. I won't paste the content of my post in this
email but I'll provide a tl;dr and eventually come back with the actual
reference document patch. I thought I'd drop this here in case people read my
post and were confused about what's going on there.

Ok, here's the TL;DR of what I believe we should know/do before accepting a new
language into the community:

- Define a way to share code/libraries for projects using the language
- Work on a basic set of libraries for OpenStack base services
- Define how the deliverables are distributed
- Define how stable maintenance will work
- Setup the CI pipelines for the new language

The longer and more detailed version is here:

https://blog.flaper87.com/embracing-other-languages-openstack.html

Stay tuned,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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