John, appreciate your candor and candidacy. Some questions inline for you...
On 09/26/2016 06:57 AM, John Davidge wrote:
Last year, the TC moved OpenStack away from the Integrated Release, and into The Big Tent. This removed the separation between those projects considered integral to OpenStack, and those which enhance it.
Who decides what is integral to OpenStack and what merely "enhances" it, though? The TC? The DefCore group? The Board of Directors? One might say all three groups have a say in defining what "is OpenStack", no? And therefore all three groups would decide what is "integral" to OpenStack.
Since then, the number of official projects has gone from ~12 to 60. While this was a fantastic move for community inclusivity, it has also made life harder for operators and customers
We do indeed have a long way to go in improving the operator's experience for many OpenStack projects.
However, remember that many of the OpenStack projects came into existence because operators were asking for a certain use case to be fulfilled. I'm uncertain how putting some projects into a not-really-OpenStack-but-related bucket will help operators much. Is the pain for operators that there are too many projects in OpenStack, or is the pain that those projects are not universally installable or usable in the same fashion?
and has diminished the focus on OpenStack’s core purpose.
What is OpenStack's core purpose? :) The OpenStack mission is intentionally encompassing of a wide variety of users and use cases. The Big Tent, by the way, did not affect this fact. The OpenStack mission pre-exists the Big Tent. All the Big Tent did was say that projects that wanted to be official OpenStack projects needed to follow the 4 Opens, submit to TC governance, and further the mission of OpenStack.
It sounds like you would like to limit the scope of the OpenStack mission, which is not the same as getting rid of the Big Tent. If that's the case, hey, totally cool with me :) But let's be specific about what it is you are suggesting.
Managing every team under one roof has led to issues for both the core and the newer projects. The experience so far has taught us that there isn’t a single set of rules that can be helpfully applied to both.
Hmm, I disagree about that. I think that experience actually *has* shown us that there is a single set of rules that can/should be applied to all projects that wish to be called an OpenStack project.
I believe that now is the time to take The Big Tent’s ideas and iterate upon them to create a new model that can promote inclusivity, while still preserving a clear focus for the core of OpenStack. The main points of this new model are: * Define OpenStack as its core components
Which components would these be? Folks can (and will) argue with you that a particular service is critical and should be considered core. But differing opinions here will lead to a decision-making inertia that will be difficult to overcome. You've been warned. :)
* Introduce a new home for complementary projects - The OpenStack Family * Reinstate Stackforge as the primary incubator for new projects
Having Stackforge as a separate Github organization and set of repositories was a maintenance nightmare due to the awkwardness of renaming projects when they "moved into OpenStack".
Also, reminder: The Big Tent != the dissolution of Stackforge.
OpenStack will once again be a focused set of closely aligned projects working together to provide an operating system for the datacenter.
As I've said before, this was never really reality, even since the beginning of OpenStack. :)
> The
OpenStack Family will provide a home for projects that work to improve the experience of an OpenStack cloud (think Ceilometer, Heat, etc), while protecting them from some of the more prescriptive rules that go with being a core OpenStack component. Stackforge will be the main focus of early-stage innovation, with a clearly defined path towards graduation into The OpenStack Family.
Who gets to decide this graduation? The TC? The DefCore committee? The Board of Directors? What criteria would you use in the graduation requirements? Would they be technical criteria or governance/process criteria?
What technical benefits would graduating give to a project? If no technical benefits -- the benefits would be entirely marketing, political or reputational -- then should the *Technical* Committee be the group that decides whether a project graduates?
These are all questions that you will inevitably be asked to consider when you go (back down) the route you suggest. So, I think it's worth responding here in your TC candidacy mail.
All the best, -jay > I believe that this model[4] can go a long way
towards solving many of the pain points that we are seeing with OpenStack today. This transformation is one that I think is very important for the future of OpenStack. We have a fantastic project surrounded by a talented community, of which I am very proud to call myself a member. Trust me with your vote, and I’ll work hard to ensure its continued success. Thank you for your consideration, John [1] https://www.youtube.com/watch?v=pmpRhcwyJIo - Curvature [2] https://www.youtube.com/watch?v=GjuF-3fB0IQ - IPv6 Prefix Delegation [3] https://www.youtube.com/watch?v=4ag1NiCVBDo - Neutron Purge [4] https://johndavidge.wordpress.com/mr-openstack-tear-down-this-tent/ ------------------------------------------------------------------------ Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __________________________________________________________________________ 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
