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 __________________________________________________________________________ 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
