Open Stack

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.

- Graham

>>
>>> Doug
>>>
>>>>
>>>> - Graham
>>>>
>>>> 0 -
>>>> https://governance.openstack.org/tc/reference/project-testing-interface.html
>>>
>>> __________________________________________________________________________
>>> 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
>>>
> 
> __________________________________________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180423/af0b7fcc/attachment.sig>