Re: [openstack-dev] [all][elections][TC] TC candidacy
On Mon, Oct 03, 2016 at 10:53:30AM -0700, John Dickinson wrote: > > > On 27 Sep 2016, at 9:21, Sean McGinnis wrote: > > > I would like to announce my candidacy for a position on the Technical > > Committee. > > > > > Sean, > > Are there some specific areas of complexity that you would like to change in > OpenStack now? How would you change them? Are there things you see happening > in OpenStack now that need to be stopped because they will produce too much > complexity? > > > --John > > I wrote a response earlier today, but now I don't see it. Apologies if this is a second response, but rephrasing are restating never hurts to communicate ideas. ;) I think most of us are engineers. It is usually our natural tendency to over-engineer solutions. I've been down this road far too many times, and I hope I can help identify when that's happening and help steer things to a simpler solution. I will state - I am not coming in to this with a big agenda. I don't look to pull down any tents or build any coliseums. I think it's important to have a diverse mix of members on the TC. Varying view points and good arguments, as long as they are technical arguments, are import for something like the TC to be effective in making good long term decisions. As part of these discussions, I also think it's important to keep in mind what our real goals are and make sure we are not going down a certain path just because it's what's considered the "OpenStack way". We also need to make sure all voices are heard. I think we've seen many cases on the mailing list where early agreement to an idea has deterred others from expressing their doubts about it. We need to make sure we're open to other viewpoints and listening to input. We need to help make it easy for new contributors to get involved. If there are 10 steps to go through and two weeks of reading governance documents and (outdated) wiki instructions, then the only new contributors we will get are the ones being assigned to OpenStack by their employers. I'm really just rambling now. I assure you, my earlier response was much more eloquent and concise. :) Sean __ 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
Re: [openstack-dev] [all][elections][TC] TC candidacy
On 27 Sep 2016, at 9:21, Sean McGinnis wrote: > I would like to announce my candidacy for a position on the Technical > Committee. > > I work for Dell EMC with over a decade (quite a bit over, but I don't want to > think about that) in storage and software development. I have been involved in > OpenStack since the Icehouse cycle and have served as the Cinder PTL since the > Mitaka release. > > I think it's important to have active PTLs on the TC. TC decisions need to be > grounded in the reality of day to day project development. I think it will > also > be good for me as a PTL to be forced to take a wider view of things across the > whole ecosystem. > > I think outreach and education is important to spread interest in OpenStack > and > provide awareness to reach new people. I've spoken at several Summits, as well > as OpenStack Days events and (more pertinent to Cinder) at Storage Network > Industry Association (SNIA) events. > > I think it's important to get feedback from actual operators and end users. I > have tried to reach out to these users as well as attend the Ops Midcycle in > order to close that feedback loop. > > I would continue to work towards these things and bring that feedback to the > TC - making sure the decisions we make have the end user in mind. > > Another goal for me is simplicity. With the Big Tent, more interacting, > projects, and lot's of competing interests, things have gotten much more > complicated over the last several releases. > > I say this while acknowledging within Cinder - while I have been PTL - a lot > of > complexity has been added. In most cases there are very valid reasons for > these > changes. So even with a desire to make things as simple as possible, I > consider > myself a pragmatist and recognize that complexity is sometimes unavoidable in > order to move forward. But one thing I would try to focus on as a TC member > would be to reduce complexity anywhere it's possible and where it makes sense. Sean, Are there some specific areas of complexity that you would like to change in OpenStack now? How would you change them? Are there things you see happening in OpenStack now that need to be stopped because they will produce too much complexity? --John > > It would be an honor to serve as a member of the TC and help do whatever I can > to help the community continue to succeed and grow. > > Thank you for your consideration. > > Sean McGinnis (smcginnis) > > __ > 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 signature.asc Description: OpenPGP digital signature __ 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
Re: [openstack-dev] [all][elections][TC] TC Candidacy
I noticed a good statement, marked it inline. On 9/28/16 7:24 AM, John Davidge wrote: > Hi Zane, > > Thanks for pointing this out! My interpretation of the StackForge > Retirement page[1] was wrong on that point. I've updated the blog post to > reflect that (without removing the original interpretation). > > The discussion about renaming git repos is a bit of a red herring, because > what we're really talking about is what it *means* to be in Stackforge vs. > OpenStack vs. OpenStack Family, not which git namespace a project should > live in. Apologies if I didn't make that clear. > > Like many of us, I do my best to keep up with historical context, but when > there is so much contradictory information/opinion out there about what > OpenStack is/isn't was/wasn't it can be a struggle at times. The crux of """ > my proposal is aiming to solve that by not trying to be everything to > everyone under one tent - by defining sensible boundaries to separate the > different goals of the community. """ +1000 to sensible boundaries. the key factor is to strike the balance. > > All the best, > > John > > [1] https://wiki.openstack.org/wiki/Stackforge_Namespace_Retirement > > On 9/27/16, 5:13 PM, Zane Bitter wrote: > >> On 27/09/16 06:19, John Davidge wrote: 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". >>> There's no reason that this would need a separate github structure, just >>> separate messaging and rules. >> That's exactly what we have now. >> >> This statement on your blog: >> >> "[StackForge] was retired in October 2015, at which point all projects >> had to move into the OpenStack Big Tent or leave entirely." >> >> is completely false. That never happened. There are still plenty of >> repos on git.openstack.org that are not part of the Big Tent. At no time >> has any project been required to join the Big Tent in order to continue >> being hosted. >> >> Maybe you should consider reading up on the historical background to >> these changes. There are a lot of constraints that have to be met - from >> technical ones like the fact that it's not feasible to rename git repos >> when they move into or out of the official OpenStack project, to legal >> ones like how the TC has to designate projects in order to trigger >> certain rights and responsibilities in the (effectively immutable) >> Foundation by-laws. Rehashing all of the same old discussions without >> reference to these constraints is unlikely to be productive. >> >> cheers, >> Zane. >> >> __ >> 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 > > > 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 -- Thanks, Nikhil __ 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
Re: [openstack-dev] [all][elections][TC] TC Candidacy
Hi Zane, Thanks for pointing this out! My interpretation of the StackForge Retirement page[1] was wrong on that point. I've updated the blog post to reflect that (without removing the original interpretation). The discussion about renaming git repos is a bit of a red herring, because what we're really talking about is what it *means* to be in Stackforge vs. OpenStack vs. OpenStack Family, not which git namespace a project should live in. Apologies if I didn't make that clear. Like many of us, I do my best to keep up with historical context, but when there is so much contradictory information/opinion out there about what OpenStack is/isn't was/wasn't it can be a struggle at times. The crux of my proposal is aiming to solve that by not trying to be everything to everyone under one tent - by defining sensible boundaries to separate the different goals of the community. All the best, John [1] https://wiki.openstack.org/wiki/Stackforge_Namespace_Retirement On 9/27/16, 5:13 PM, Zane Bitter wrote: >On 27/09/16 06:19, John Davidge wrote: >>> 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". >> There's no reason that this would need a separate github structure, just >> separate messaging and rules. > >That's exactly what we have now. > >This statement on your blog: > >"[StackForge] was retired in October 2015, at which point all projects >had to move into the OpenStack Big Tent or leave entirely." > >is completely false. That never happened. There are still plenty of >repos on git.openstack.org that are not part of the Big Tent. At no time >has any project been required to join the Big Tent in order to continue >being hosted. > >Maybe you should consider reading up on the historical background to >these changes. There are a lot of constraints that have to be met - from >technical ones like the fact that it's not feasible to rename git repos >when they move into or out of the official OpenStack project, to legal >ones like how the TC has to designate projects in order to trigger >certain rights and responsibilities in the (effectively immutable) >Foundation by-laws. Rehashing all of the same old discussions without >reference to these constraints is unlikely to be productive. > >cheers, >Zane. > >__ >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 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
Re: [openstack-dev] [all][elections][TC] TC Candidacy
On 09/27/2016 06:19 AM, John Davidge wrote: >> 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. > > We may have to agree to disagree here. Look at recent efforts to enforce > python 3 compatibility, for example. Some projects had reasons why they > didn't want to, others had reasons why they couldn't, and some simply > didn't view it as a priority. We'd be much more productive in defining and > enforcing rules like this if there was a narrower scope of projects they > applied to. To clarify on this point, the main projects that said this probably wasn't doable in the way first proposed, were within the smaller tent that you defined earlier. The reason this particular goal is challenging isn't really the big tent, it's the legacy that larger projects carry forward, which just means the work takes more than a cycle to do. -Sean -- Sean Dague http://dague.net __ 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-dev] [all][elections][TC] TC candidacy
I would like to announce my candidacy for a position on the Technical Committee. I work for Dell EMC with over a decade (quite a bit over, but I don't want to think about that) in storage and software development. I have been involved in OpenStack since the Icehouse cycle and have served as the Cinder PTL since the Mitaka release. I think it's important to have active PTLs on the TC. TC decisions need to be grounded in the reality of day to day project development. I think it will also be good for me as a PTL to be forced to take a wider view of things across the whole ecosystem. I think outreach and education is important to spread interest in OpenStack and provide awareness to reach new people. I've spoken at several Summits, as well as OpenStack Days events and (more pertinent to Cinder) at Storage Network Industry Association (SNIA) events. I think it's important to get feedback from actual operators and end users. I have tried to reach out to these users as well as attend the Ops Midcycle in order to close that feedback loop. I would continue to work towards these things and bring that feedback to the TC - making sure the decisions we make have the end user in mind. Another goal for me is simplicity. With the Big Tent, more interacting, projects, and lot's of competing interests, things have gotten much more complicated over the last several releases. I say this while acknowledging within Cinder - while I have been PTL - a lot of complexity has been added. In most cases there are very valid reasons for these changes. So even with a desire to make things as simple as possible, I consider myself a pragmatist and recognize that complexity is sometimes unavoidable in order to move forward. But one thing I would try to focus on as a TC member would be to reduce complexity anywhere it's possible and where it makes sense. It would be an honor to serve as a member of the TC and help do whatever I can to help the community continue to succeed and grow. Thank you for your consideration. Sean McGinnis (smcginnis) __ 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
Re: [openstack-dev] [all][elections][TC] TC Candidacy
On 27/09/16 06:19, John Davidge wrote: 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". There's no reason that this would need a separate github structure, just separate messaging and rules. That's exactly what we have now. This statement on your blog: "[StackForge] was retired in October 2015, at which point all projects had to move into the OpenStack Big Tent or leave entirely." is completely false. That never happened. There are still plenty of repos on git.openstack.org that are not part of the Big Tent. At no time has any project been required to join the Big Tent in order to continue being hosted. Maybe you should consider reading up on the historical background to these changes. There are a lot of constraints that have to be met - from technical ones like the fact that it's not feasible to rename git repos when they move into or out of the official OpenStack project, to legal ones like how the TC has to designate projects in order to trigger certain rights and responsibilities in the (effectively immutable) Foundation by-laws. Rehashing all of the same old discussions without reference to these constraints is unlikely to be productive. cheers, Zane. __ 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
Re: [openstack-dev] [all][elections][TC] TC Candidacy
Thanks for the questions Jay, answers inline. On 9/26/16, 8:39 PM, Jay Pipes wrote: >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. This will undoubtedly be the most difficult part of the transition, so making these decisions transparently will be essential. As a starting point I would suggest we use our existing definitions of Core and Optional services found here: https://www.openstack.org/software/ Everything in the 'Core' section would fall within the definition of OpenStack, everything else would live in the OpenStack Family. This isn't a change that would happen overnight, and of course we¹d seek many rounds of input from all interested parts of the community. >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? Absolutely, listening to operators should continue to be the primary driver for a lot of our decision making. For the last 3 or 4 summits I've found the operator feedback sessions to be the most valuable, and at least one led directly to a new feature (neutron purge). Not being an operator myself I'd defer to seeking feedback from the ops community during this process, but a few Big Tent related issues I've heard include: * Do I need to support *all* of these projects? * Why doesn¹t everything follow the same release schedule any more? * How many of these are mature enough to be useful? >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. OpenStack does not have a core purpose. Not one that everyone agrees on anyway. Some would like it to be an Apache-like collection of loosely related open source projects. Others would like to see it be a laser-focused operating system for the data center. I'd say that it started out closer to the latter and is slowly drifting towards the former. The discussion surrounding the "Write down OpenStack Principles" patch has shown us that the closest we've had to an official mission statement until now was the result of a TC vote in 2011: "A single product made of a lot of independent, but cooperating, components." Now obviously this is somewhat vague and open to interpretation, but to me the "single product" part suggests a level of focus that is missing today. This puts us in the position of deciding whether we need to re-focus OpenStack to better match the mission statement, or change our mission statement to better reflect reality. I'd like to do a bit of both. Limit the scope of OpenStack to that of its core components, while providing a framework for official projects that enhance its capabilities. >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. We may have to agree to disagree here. Look at recent efforts to enforce python 3 compatibility, for example. Some projects had reasons why they didn't want to, others had reasons why they couldn't, and some simply didn't view it as a priority. We'd be much more productive in defining and enforcing rules like this if there was a narrower scope of projects they applied to. >> * 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. :) See above. This definition already exists, but I acknowledge that it will need to be iterated upon. I'd like to point out that there will be benefits of being in the OpenStack Family, such as not needing to comply with the more prescriptive rules as
Re: [openstack-dev] [all][elections][TC] TC Candidacy
On 2016-09-26 15:39:23 -0400 (-0400), Jay Pipes wrote: [...] > >* 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. [...] Also a reminder that this wouldn't be a reinstatement. While it was sometimes common for people without a clear understanding of community process to assume there was a requirement that projects had to start in Stackforge and then graduate to being Official, that's not actually how incubation worked. In fact, Stackforge was (and still is though not by that name any longer as we retired the branding around it) just a label for unofficial projects. The "incubated" projects before the big tent were semi-official, could use the "openstack" Git namespace (back when we still restricted it), could publish to docs.openstack.org, and so on. -- Jeremy Stanley __ 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
Re: [openstack-dev] [all][elections][TC] TC Candidacy
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
[openstack-dev] [all][elections][TC] TC Candidacy
Hi everyone, I'd like to submit my candidacy for the OpenStack Technical Committee. You may know me as john-davidge on IRC. I've been an active member of the OpenStack community since 2012 (Folsom). I met many of you for the first time while presenting the Curvature Network Visualization Dashboard[1] at the Grizzly Summit in Portland. Since then I've been working 100% upstream, mostly in neutron[2][3], and for a couple of different sponsors. Right now I'm employed in the OpenStack Innovation Center (OSIC) - a joint venture between Rackspace and Intel - where I'm leading a small team contributing to neutron, and helping to shape the OSIC development roadmap. Over the years I have seen and participated in a lot of the changes that have led our community to where it is today. I've experienced the things that have improved our lives as developers, and operators, as well as the things that have caused us difficulties. I know where I would like to see OpenStack head in the future, and I feel strongly about making it a success. The most important thing that I would like to see changed is the overarching framework under which all of OpenStack operates: The Big Tent. 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. 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, and has diminished the focus on OpenStack's core purpose. 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. 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 * Introduce a new home for complementary projects - The OpenStack Family * Reinstate Stackforge as the primary incubator for new projects OpenStack will once again be a focused set of closely aligned projects working together to provide an operating system for the datacenter. 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. 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
