Open Stack

Excerpts from Graham Hayes's message of 2018-04-23 17:23:20 +0100:
> On 23/04/18 17:14, Doug Hellmann wrote:
> > Excerpts from Graham Hayes's message of 2018-04-23 16:27:04 +0100:
> >> On 23/04/18 16:04, Doug Hellmann wrote:
> >>> Excerpts from Graham Hayes's message of 2018-04-23 12:15:24 +0100:
> >>>> 7On 20/04/18 22:26, Doug Hellmann wrote:
> >>>> <snip/>
> >>>>> Without letting the conversation devolve too much into a discussion
> >>>>> of Adjutant's case, please talk a little about how you would evaluate
> >>>>> a project's application in general.  What sorts of things do you
> >>>>> consider when deciding whether a project "aligns with the OpenStack
> >>>>> Mission," for example?
> >>>>>
> >>>>> Doug
> >>>>>
> >>>>
> >>>> For me, the most important thing for a project that wants to join is
> >>>> that they act like "one of us" - what I think ttx refered to as "culture
> >>>> fit".
> >>>>
> >>>> This is fairly wide ranging, but includes things like:
> >>>>
> >>>> * Do they use the PTIs[0]
> >>>> * Do they use gerrit, or if they use something else, do they follow
> >>>>   the same review styles and mechanisms?
> >>>> * Are they on IRC?
> >>>> * Do they use the mailing list for long running discussion?
> >>>>   ** If a project doesn't have long running discussions and as a result
> >>>>      does not have ML activity, I would see that as OK - my problem
> >>>>      would be with a team that ran their own list.
> >>>> * Do they use standard devstack / -infra jobs for testing?
> >>>> * Do they use the standard common libraries (where appropriate)?
> >>>>
> >>>> If a project fails this test (and would have been accepted as something
> >>>> that drives the mission), I see no issue with the TC trying to bring
> >>>> them into the fold by helping them work like one of us, and accepting
> >>>> them when they have shown that they are willing to change how they
> >>>> do things.
> >>>>
> >>>> For the "product" fit, it is a lot more subjective. We used to have a
> >>>> system (pre Big Tent) where the TC picked "winners" in a space and
> >>>> blessed one project as the way to do $thing. Then, in big tent we
> >>>> started to not pick winners, and allow anyone who was one of us, and
> >>>> had a "cloud" application.
> >>>>
> >>>> Recently, we have moved back to seeing if a project overlaps with
> >>>> another. The real test for this (from my viewpoint) is if the
> >>>> perceived overlap is an area that the team that is currently in
> >>>> OpenStack is interested in pursuing - if not we should default to
> >>>> adding the project.
> >>>
> >>> We've always considered overlap to some degree, but it has come up
> >>> more explicitly in a few recent discussions because of the nature
> >>> of the projects.  Please see the other thread on this topic [1].
> >>>
> >>> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-April/129661.html
> >>>
> >>>> Personally, if the project adds something that we currently lack,
> >>>> and have lacked for a long time (not to get too close to the current
> >>>> discussion), or tries to reduce the amount of extra tooling that
> >>>> deployers currently write in house, we should welcome them.
> >>>>
> >>>> The acid test for me is "How would I use this?" or "Have I written
> >>>> tooling or worked somewhere that wrote tooling to do this?"
> >>>>
> >>>> If the answer is yes, it is a good indication that they fit with the
> >>>> mission.
> >>>
> >>> This feels like the ideal open source approach, in which contributors
> >>> are "scratching their own itch." How can we encourage more deployers
> >>> and users of OpenStack to consider contributing their customization
> >>> and integration projects? Should we?
> >>
> >> I think a lot of our major users are good citizens and are doing some or
> >> all of this work in the open - we just have a discoverability issue.
> >>
> >> A lot of the benefit of joining the foundation as a project, is the
> >> increased visibility gained from it, so that others who are deploying
> >> OpenStack in a similar layout can find a project and use it.
> >>
> >> I think at the very least we should find a way to promote them (this
> >> is where constellations could really help, as we could add non member
> >> projects to constellations where they are appropriate.
> > 
> > Do you foresee any issues with adding unofficial projects to the
> > constellations?
> > 
> > Doug
> 
> No (from my viewpoint anyway) - I think they will be important to
> include in any true collection of use cases - for example we definitely
> will want to have a "PaaS" Constellation that includes things like
> Kubernetes, Cloud Foundry and / or OpenShift. We need to show how
> OpenStack works in the entire open source infrastructure community
> and not just how it works internally - and showing how you can use other
> open source software components *with* OpenStack is vital for that.

Would you make a distinction between things that have their own
community like kubernetes, and things that might consider themselves
on track to be part of the OpenStack community one day?

Doug