On 17/01/17 13:00, Fox, Kevin M wrote: > Your right, it is not what the big tent was about, but the big tent had some > unintended side affects. The list, as you stated: > > * No longer having a formal incubation and graduation period/review for > applying projects > * Having a single, objective list of requirements and responsibilities > for inclusion into the OpenStack development community > * Specifically allowing competition of different source projects in the > same "space" (e.g. deployment or metrics) > > Turned into (my opinion): > > #1, projects, having a formal incubation/graduation period had the > opportunity to get feedback on what they could do to better integrate with > other projects and were strongly encouraged to do so to make progress towards > graduation. Without the formality, no one tended to bother. > > #2, Not having a single, objective list of requirements/responsibility: I > believe not having a list made folks take a hard look at what other projects > were doing and try harder to play nice in order to get graduated or risk the > unknown of folks coming back over and over and telling them more integration > was required. > > #3, the benefits/drawbacks of specifically allowing competition is rather > hard to predict. It can encourage alternate solutions to be created and > create a place where better ideas can overcome less good ideas. But it also > removes pressure to cooperate on one project rather then just take the > sometimes much easier route of just doing it yourself in your own project. > > I'm not blaming the big tent for all the ills of the OpenStack world. It has > had some real benefits. This problem is something bigger then the big tent. > It preexisted the tent. The direction the pressure to share was very > unidirectional pre big tent, applied to new projects much more then old > projects. > > But, I'm just saying the Big Tent had an (unintended) net negative affect > making this particular problem worse. > > Looking at the why of a problem is one of the important steps to formulating > a solution. OpenStack no longer has the amount of tooling to help elevate the > issue it had under the time before the Big Tent. Nothing has come up since to > replace it. > > I'm not stating that the big tent should be abolished and we go back to the > way things were. But I also know the status quo is not working either. How do > we fix this? Anyone have any thoughts?
Could we create a new tag (at https://governance.openstack.org/tc/reference/tags/) to indicate the project is trusted to be integrated. Then, if there is a existing project want to use a feature in the trusted-integrated project, then no new wheel. To be more clear, the integration is a force integration. Look at this list, https://www.openstack.org/software/project-navigator/ most of the projects has been developed more than 3 years, unfortunately, they're not trusted, on the contrary, sometimes we're brave to use some 3rd party library very new. That's a little ironic. > > Thanks, > Kevin > ________________________________________ > From: Jay Pipes [jaypi...@gmail.com] > Sent: Monday, January 16, 2017 1:57 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects > trying to avoid Barbican, still? > > On 01/16/2017 04:09 PM, Fox, Kevin M wrote: >> If the developers that had issue with the lack of functionality, >> contributed to Barbican rather then go off on their own, the problem >> would have been solved much more quickly. The lack of sharing means >> the problems don't get fixed as fast. > Agreed completely. > >> As for operators, If the more common projects all started depending >> on it, it would be commonly deployed. > Also agreed. > >> Would the operators deploy Barbican just for Magnum? maybe not. maybe >> so. For Magnum, Ironic, and Sahara, more likely . Would they deploy >> it if Neutron and Keystone depended on it, yeah. they would. And then >> all the other projects would benefit from it being there, such as >> Magnum. > Totally agreed. > > > The sooner OpenStack as a whole can decide on some new core >> components so that projects can start hard depending on them, the >> better I think. That process kind of stopped with the arrival of the >> big tent. > You are using a false equivalence again. > > As I've mentioned numerous times before on the mailing list, the Big > Tent was NOT either of these things: > > * Expanding what the "core components" of OpenStack > * Expanding the mission or scope of OpenStack > > What the Big Tent -- technically "Project Structure Reform" -- was about > was actually the following: > > * No longer having a formal incubation and graduation period/review for > applying projects > * Having a single, objective list of requirements and responsibilities > for inclusion into the OpenStack development community > * Specifically allowing competition of different source projects in the > same "space" (e.g. deployment or metrics) > > What you are complaining about (rightly IMHO) regarding OpenStack > project contributors not contributing missing functionality to Barbican > has absolutely nothing to do with the Big Tent: > > There's no competing secret storage project in OpenStack other than > Barbican/Castellan. > > Furthermore, this behaviour of projects choosing to DIY/NIH something > that existed in other projects was around long before the advent of the > Big Tent. In fact, in this specific case, the Magnum team knew about > Barbican, previously depended on it, and chose to make Barbican an > option not because Barbican wasn't OpenStack -- it absolutely WAS -- but > because it wasn't commonly deployed, which limited their own adoption. > > What you are asking for, Kevin, is a single opinionated and consolidated > OpenStack deployment; a single OpenStack "product" if you will. This is > a perfectly valid request. However it has nothing to do with the Big > Tent governance reform. > > Best, > -jay > > __________________________________________________________________________ > 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 > > __________________________________________________________________________ > 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 -- Cheers & Best regards, FeiLong Wang (王飞龙) -------------------------------------------------------------------------- Senior Cloud Software Engineer Tel: +64-48032246 Email: flw...@catalyst.net.nz Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -------------------------------------------------------------------------- __________________________________________________________________________ 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
