Open Stack

On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham <graham.hayes at hpe.com> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161107/f4171091/attachment.html>