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: [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
