Re: [openstack-dev] Avoiding regression in project governance
On Mar 10, 2015, at 6:00 PM, Devananda van der Veen devananda@gmail.com wrote: On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell lau...@openstack.org mailto:lau...@openstack.org wrote: - Operators don’t want the wild west. They are nervous about dissolving the integrated release, because they want a strong filter and rules - dependency mapping, release timing, test coverage - around the most widely adopted projects. I’m not sure we’re giving them a lot of confidence. We're not lowering the testing standards of existing projects... can you be more clear as to what is creating this concern? The concern they raised was not necessarily about a testing standard for any individual project, but more about the combination of testing across that set of the most commonly deployed projects. In other words, if there is no “kernel” grouping, it potentially makes it harder to understand the full set of dependencies, how well the integration between nova and glance is tested, and things along those lines. One item that came up that a lot of them seemed to appreciate, for example, was that there was some forcing function for the integrated projects that kept their dependencies somewhat aligned and allowed them to understand what all they might need to be running to deploy any set of those projects. If the projects are all split apart, now they would have to deal with understanding that separately for each project they intend to deploy. Sean had mentioned in the session that some of this was probably already going to be changing, but I do think it was an interesting point that seemed to be very widely held among the operators there. For tags, I think defining a set of projects based on a broad reference architecture / use case like base compute” or “compute kernel” and “object storage” is critical. Those tags will imply the projects share common dependencies and are released together. If we categorize tags that can be applied, compute kernel” could be a higher level category and more prominent. Defining those initial tags should provide enough direction and confidence to start considering new projects. I've started drafting some tags for layers or use cases -- I'm sure they'll get expanded on. I'll post a link once I've uploaded to gerrit. That’s great news. I think defining those important tags will go a long way in giving people confidence in the process and moving forward. I believe this is the one you started: https://review.openstack.org/#/c/163236/ Might be worth sharing over to the operators mailing list where Subbu has a message about some of the discussions as well: http://lists.openstack.org/pipermail/openstack-operators/2015-March/006511.html http://lists.openstack.org/pipermail/openstack-operators/2015-March/006511.html I’m sorry it took me a while to respond to this. Thanks for taking time to provide feedback last week. __ 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] Avoiding regression in project governance
Ed Leafe wrote: [...] So what is production-ready? And how would you trust any such designation? I think that it should be the responsibility of groups outside of OpenStack development to make that call. We discussed that particular point at the Ops Summit: how to describe and objectively define maturity ? The developers (or the members of the TC) are obviously not the best placed to make such a call, the information needs to come from downstream users. We concluded that maturity is difficult to define in a single tag, and that everyone will have a different definition for it. What we need to do is define and apply a number of tags that help downstream consumers assess the degree of maturity of a project, for their own definition of maturity. For example we discussed the possibility of an operationability (ew) tag, that would be applied to projects which indicate some operational maturity (like not requiring you to manually push rows in database to run it). We discussed availability (packaging in open source distributions) and popularity (as reported in surveys and/or public cloud deployments). A working group will be put in place with operators to further refine these concepts -- Thierry Carrez (ttx) 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 11:46 AM, Doug Hellmann d...@doughellmann.com wrote: On Tue, Mar 10, 2015, at 12:29 PM, Russell Bryant wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. I think we made it pretty clear that we would be taking approvals slowly, and that we might not approve any new projects before the summit, precisely for the reasons you state here. I have found the submitted proposals Right, but we want it to be clear we're not approving new project proposals at this point so everyone is on the same page. Thanks, [1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ [2] http://governance.openstack.org/reference/new-projects-requirements.html [3] http://governance.openstack.org/reference/tags/index.html [4] http://governance.openstack.org/reference/incubation-integration-requirements.html -- Russell Bryant __ 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 __ 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] Avoiding regression in project governance
On 03/10/2015 12:47 PM, Doug Hellmann wrote: On Tue, Mar 10, 2015, at 12:46 PM, Doug Hellmann wrote: I think we made it pretty clear that we would be taking approvals slowly, and that we might not approve any new projects before the summit, precisely for the reasons you state here. I have found the submitted proposals Oops I have found the existing applications useful for thinking about what tags we need, and what other criteria we might be missing (Joe's proposal to add a team employer diversity requirement is one example). That's a good example of a requirement we already had but haven't yet replaced. I don't think there's consensus about how far off we are from being able to approve projects. If everyone thinks of course, we have a ton of work to do before we can consider approving the first one, then great, but I didn't think that was the case. -- Russell Bryant __ 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] Avoiding regression in project governance
Some clarification about Murano: 3. *Maybe*. Not sure about the scope, it is fairly broad and there may be some open ended corners, such as some references to billing. On the other hand an application catalog sounds really useful and like a measured progression for OpenStack as a whole. Murano may overlap with glance's stated mission of To provide a service where users can upload and discover data assets that are meant to be used with other services, like images for Nova and templates for Heat. Glance mission was changed with active help from Murano team side as Murano needs to have a storage for Applications definitions. That is why one of the Murano engineers right now is working on landing Artifact repository which was initially drafted in Murano team and then re-architected to be useful for other projects like Heat and Nova. Once artifacts are landed in Kilo release[all patches are on review] Murano will use Glance to store all packages and related objects, so there will be no any overlap with Glance. Murano also relies heavily on the Mistral service which is still in stackforge itself. This is a wrong perception. Murano currently does not use Mistral at all. It will use it once cross project initiative Congress-Murano-Mistral will be implemented. Right now Murano works without Mistral installed. Murano will use congress and Mistral to offload some of the logic outside of Murano to have very simple life-cycle workflows controlled by policies and Mistral flows. Thanks Gosha On Wed, Mar 11, 2015 at 7:28 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-03-10 23:00:16 + (+), Devananda van der Veen wrote: Many of those requirements were subjective (well tested, well documented, etc) and had to be evaluated by the TC. Are these the sort of tags you're referring to? If so, and if the TC delegated responsibility to manage the application of those tags (say, QA team manages the 'well-tested' tag), would that be sufficient? [...] Yep, that's exactly what I'm hoping for. But without those in place yet I worry that we'll end up turning away lots of new requests for help from projects coming forward thinking they're suddenly entitled by virtue of being OpenStack and not really have any common criteria to point them at so that they can work toward getting more priority. -- 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 11:29 AM, Russell Bryant rbry...@redhat.com wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. +1000 to this. I don't see how we can reliably approve new project proposals here when we haven't even defined the second half of the new governance model (tags). It's worth putting the breaks on things here until that settles out, or we'll find ourselves in an even bigger mess. The previous governance model at least made an attempt at focusing work and projects and not allowing the proliferation of possibly overlapping projects. Lets not rush into approving new things until we're comfortable the new governance model will stick to the core principles the old governance model was successful at. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. This is the litmus test for tags, so agree. Thanks, Kyle Thanks, [1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ [2] http://governance.openstack.org/reference/new-projects-requirements.html [3] http://governance.openstack.org/reference/tags/index.html [4] http://governance.openstack.org/reference/incubation-integration-requirements.html -- Russell Bryant __ 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
Re: [openstack-dev] Avoiding regression in project governance
-Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: 11 March 2015 20:40 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Avoiding regression in project governance On 2015-03-11 19:06:21 + (+), Tim Bell wrote: [...] I think we can make this work. Assuming more than N (to my mind 5 or so) deployments report they are using project X, we can say that this is used in production/POC/... and the number of nodes/hypervisors/etc. This makes it concrete and anonymous to avoid the fishing queries. It also allows our community to enter what they are doing in one place rather than answering multiple surveys. I am keen to avoid generic queries such as How many hypervisors are installed for public clouds using Xen but if we have an agreement that 5 avoids company identification, I feel this is feasible. [...] I'm mildly concerned that this adds a strong incentive to start gaming responses to/participation in the user survey going forward, once it gets around that you just need N people to take the survey and claim to be using this project in production so that it can get the coveted production-ready tag. I'm probably a little paranoid and certainly would prefer to assume good faith on the part of everyone in our community, but as the community continues to grow that faith gets spread thinner and thinner. Agreed on the worry... I'd hope that gaming the user survey would be relatively difficult and is already a risk. However, there are lots of other motivations for influencing the user survey and we need to address these anyway. I don't think it is perfect or universal but it seems better than a doodle for each project which is easier to influence. Tim -- 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 __ 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] Avoiding regression in project governance
On 2015-03-11 19:06:21 + (+), Tim Bell wrote: [...] I think we can make this work. Assuming more than N (to my mind 5 or so) deployments report they are using project X, we can say that this is used in production/POC/... and the number of nodes/hypervisors/etc. This makes it concrete and anonymous to avoid the fishing queries. It also allows our community to enter what they are doing in one place rather than answering multiple surveys. I am keen to avoid generic queries such as How many hypervisors are installed for public clouds using Xen but if we have an agreement that 5 avoids company identification, I feel this is feasible. [...] I'm mildly concerned that this adds a strong incentive to start gaming responses to/participation in the user survey going forward, once it gets around that you just need N people to take the survey and claim to be using this project in production so that it can get the coveted production-ready tag. I'm probably a little paranoid and certainly would prefer to assume good faith on the part of everyone in our community, but as the community continues to grow that faith gets spread thinner and thinner. -- 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] Avoiding regression in project governance
On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote: The holy grail of this system would be the suitable for production deployment tag, but no one has figured out how to define it yet. Are crazy ideas welcome in this phase? I start with 2 below: Preface: an idea circulates about visually displaying in a web page the projects.yaml file and the tags in there. Visitors would be able to browse the list of projects and sort, pick, search and find what they need from a nice representation of the 'big tent'. 1) how about we pull the popularity of OpenStack projects as reported in the User Survey and display such number on the page where we list the projects? What if, together with the objective tags managed by TC and community at large, we show also the number of known deployment as guidance? 2) there are some 'fairly objective' indicators of quality of open source code, developed in a handful of academic projects that I'm aware of (Calipso and sos-opensource.org come to mind, but there are other). Maybe we can build a tool that pulls those metrics from each of our repositories and provides more guidance to visitors so they can form their own mind? Nobody can really vet for 'production ready' but probably we can provide data for someone to get a more informed opinion. Too crazy? .stef __ 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] Avoiding regression in project governance
-Original Message- From: Stefano Maffulli [mailto:stef...@openstack.org] Sent: 11 March 2015 03:16 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote: The holy grail of this system would be the suitable for production deployment tag, but no one has figured out how to define it yet. Are crazy ideas welcome in this phase? I start with 2 below: Preface: an idea circulates about visually displaying in a web page the projects.yaml file and the tags in there. Visitors would be able to browse the list of projects and sort, pick, search and find what they need from a nice representation of the 'big tent'. 1) how about we pull the popularity of OpenStack projects as reported in the User Survey and display such number on the page where we list the projects? What if, together with the objective tags managed by TC and community at large, we show also the number of known deployment as guidance? I think we can make this work. Assuming more than N (to my mind 5 or so) deployments report they are using project X, we can say that this is used in production/POC/... and the number of nodes/hypervisors/etc. This makes it concrete and anonymous to avoid the fishing queries. It also allows our community to enter what they are doing in one place rather than answering multiple surveys. I am keen to avoid generic queries such as How many hypervisors are installed for public clouds using Xen but if we have an agreement that 5 avoids company identification, I feel this is feasible. It does help address the maturity question concretely. If it's in prod in 200 deployments, I would consider this to be reasonably mature. If there is only 1, I would worry. 2) there are some 'fairly objective' indicators of quality of open source code, developed in a handful of academic projects that I'm aware of (Calipso and sos- opensource.org come to mind, but there are other). Maybe we can build a tool that pulls those metrics from each of our repositories and provides more guidance to visitors so they can form their own mind? Nobody can really vet for 'production ready' but probably we can provide data for someone to get a more informed opinion. Too crazy? If an operator says that they are using this for their production cloud and there is a reasonable profile of scalability, this is a strong (but not guaranteed) endorsement for me. There could be influence but given the survey results can be scrutinised in more detail by the people with NDA access, it would discourage this behaviour. .stef _ _ 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
Re: [openstack-dev] Avoiding regression in project governance
On Tue, Mar 10, 2015, at 10:16 PM, Stefano Maffulli wrote: On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote: The holy grail of this system would be the suitable for production deployment tag, but no one has figured out how to define it yet. Are crazy ideas welcome in this phase? I start with 2 below: Preface: an idea circulates about visually displaying in a web page the projects.yaml file and the tags in there. Visitors would be able to browse the list of projects and sort, pick, search and find what they need from a nice representation of the 'big tent'. 1) how about we pull the popularity of OpenStack projects as reported in the User Survey and display such number on the page where we list the projects? What if, together with the objective tags managed by TC and community at large, we show also the number of known deployment as guidance? 2) there are some 'fairly objective' indicators of quality of open source code, developed in a handful of academic projects that I'm aware of (Calipso and sos-opensource.org come to mind, but there are other). Maybe we can build a tool that pulls those metrics from each of our repositories and provides more guidance to visitors so they can form their own mind? Nobody can really vet for 'production ready' but probably we can provide data for someone to get a more informed opinion. Too crazy? This sort of information would be useful, but I don't think we want to turn our project governance documentation into a product guide. We should *have* a product guide, but it should live somewhere else. Doug .stef __ 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
Re: [openstack-dev] Avoiding regression in project governance
On Wed, 2015-03-11 at 17:59 -0500, Ed Leafe wrote: The longer we try to be both sides of this process, the longer we will continue to have these back-and-forths about stability vs. innovation. If I understand correctly your model, it works only for users/operators who decide to rely on a vendor to consume OpenStack. There are quite large enterprises out there who consume directly the code as it's shipped from git.openstack.org, some from trunk others from the stable release .tgz: these guys can't count on companies A, B, C or D to put resources to fix their problems, because they don't talk to those companies. One thing I like of your proposal though, when you say: So what is production-ready? And how would you trust any such designation? I think that it should be the responsibility of groups outside of OpenStack development to make that call. This problem has been bugging the European authorities for a long time and they've invested quite a lot of money to find tools that would help IT managers of the public (and private) sector estimate the quality of open source code. It's a big deal in fact when on one hand you have Microsoft and IBM sales folks selling your IT managers overpriced stuff that just works and on the other hand you have this Linux thing that nobody has heard of, it's gratis and I can find it on the web and many say it just works, too... crazy, right? Well, at the time it was and to some extent, it still is. So the EU has funded lots of research in this area. One group of researcher that I happen to be familiar with, recently has received another bag of Euros and released code/methodologies to evaluate and compare open source projects[1]. The principles they use to evaluate software are not that hard to find and are quite objective. For example: is there a book published about this project? If there is, chances are this project is popular enough for a publisher to sell copies. Is the project's documentation translated in multiple languages? Then we can assume the project is popular. How long has the code been around? How large is the pool of contributors? Are there training programs offered? You get the gist. Following up on my previous crazy ideas (did I hear someone yell keep 'em coming?), probably a set of tags like: book-exists (or book-chapter-exists) specific-training-offered translated-in-1-language (and its bigger brothers translated-in-5, translated-in-10+languages) contributor-size-high (or low, and we can set a rule as we do for the diversity metric used in incubation/graduation) codebase-age-baby, -young and -mature, (in classes, like less than 1, 1-3, 3+ years old) would help a user understand that Nova or Neutron are different from (say) Barbican or Zaqar. These are just statements of facts, not a qualitative assessment of any of the projects mentioned. At the same time, I have the impression these facts would help our users make up their mind. Thoughts? [1] http://www.ict-prose.eu/2014/12/09/osseval-prose-open-source-evaluation-methodology-and-tool/ signature.asc Description: This is a digitally signed message part __ 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] Avoiding regression in project governance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2015 02:40 PM, Jeremy Stanley wrote: I think we can make this work. Assuming more than N (to my mind 5 or so) deployments report they are using project X, we can say that this is used in production/POC/... and the number of nodes/hypervisors/etc. This makes it concrete and anonymous to avoid the fishing queries. It also allows our community to enter what they are doing in one place rather than answering multiple surveys. I am keen to avoid generic queries such as How many hypervisors are installed for public clouds using Xen but if we have an agreement that 5 avoids company identification, I feel this is feasible. [...] I'm mildly concerned that this adds a strong incentive to start gaming responses to/participation in the user survey going forward, once it gets around that you just need N people to take the survey and claim to be using this project in production so that it can get the coveted production-ready tag. I'm probably a little paranoid and certainly would prefer to assume good faith on the part of everyone in our community, but as the community continues to grow that faith gets spread thinner and thinner. Allow me to re-propose the idea that we are dealing with two separate entities here, and need two separate entities to make these calls. There is the the development side of things, where people work hard to get their ideas for OpenStack incorporated into the codebase. There is also the distribution side, where people work hard to get a single deployable package that others can take and make clouds with. So what is production-ready? And how would you trust any such designation? I think that it should be the responsibility of groups outside of OpenStack development to make that call. What would that look like? Well, let me give you an example. I have Company A that wants to be known as the simplest OpenStack distribution. I invest time and money in packaging the co-gated core along with a few helpful other projects, and make that available to my customers. There is also Company B, who wants to create the most powerful, flexible packaging of OpenStack, and takes the time to not only include the basics, but develops tools to handle the more complex situations, such as cells or HA designs. This package is not for the faint of heart, and for most businesses it would require contracting for the services of Company B in order to get their installation up and running, as well as fine-tuning it and upgrading it. There are also Company C and Company D who target other end-user needs. They all draw from the codebase that the OpenStack developers create, and, of course, give their feedback as to what changes are needed to make their particular customers happy. If they're smart, they'll supply developer cycles to help make them happen. The longer we try to be both sides of this process, the longer we will continue to have these back-and-forths about stability vs. innovation. - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJVAMjCAAoJEKMgtcocwZqLkKIP/0ReARgypM+eXnu7xDguJIF/ 6QW8RI7tdHpBFrRZfrBaRahDstFdPQiaBxj1XhFbzoKP+BrUvvfLMnxhJ5cRX0ey mz842khScuGmLFzteKvLWwyOia425CZQRnNNaHYjiwii3Agu3a5JTnUi0FeDxZi4 bD/ZFb/1OxqyVVf2eOJ/T0akVQBqB9QGGNtBnPJEmgEjUl6AhOplLnOkOl1ozRSW svlCE7Wyq/Gtl86Ksbj1rfDdArO9Hlh3lwJxaJikfV3O316kqfjx+v7JVcrwdXrK qqNtDUpC/tjlReDuDmrPixa0e8/z9Go4TiF1F6nQ4LbY8itMzRKeVbrUPrx4ojlh DOE/uOhxh8iTYKOncPsxQlfhbIk0VwzCDWZzDbRxEUpV8Jnzz1ImeosCO3D5/sRL G+Rd2gr9rsbwQxtJLA1Q2zQUqnJ6Vvsvx2BgV87ukl0kudF9X/1NaGrJRmeiKYxk UDgd0ESYnp9GQMCORcoDa6hNKnPA0yLebqOEyi5dGMwem8JHjYFDx6D9fVfkrxlQ 7Kt+SfRmm+1zsHcbZIUz6KEPAvU0cmFdbuG7DwnmKSxpPamUnn3wmpIZRDpdwGIj fY3F2dTeEYoNnTyiitLTCKZYE0KaKpFDOAN+FpDNnQJIqQMn/ksxy9/NHYvsmutD 5DE1LjWhip9IdcVVm+bT =8L0C -END PGP 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] Avoiding regression in project governance
On 11 March 2015 at 05:29, Russell Bryant rbry...@redhat.com wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. I think this is kindof missing the point of the new governance system: the bar for entry has been replaced with a bar for getting certain tags - holding back entrants because we don't have enough tags to answer all the questions we could before doesn't make anything better - we know we weren't really answering the questions folk cared about before (thats why we've revamped the governance system at all). If I understand your particular concern, its that if more projects are added folk will be more confused about what is safe or sane to deploy : I think that is a risk, but not a big one, because what was safe or sane to deploy before was already quite fuzzy. See e.g. Neutron only a couple of releases back :). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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] Avoiding regression in project governance
On 11/03/15 19:06 +, Tim Bell wrote: -Original Message- From: Stefano Maffulli [mailto:stef...@openstack.org] Sent: 11 March 2015 03:16 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance On Tue, 2015-03-10 at 15:23 -0700, James E. Blair wrote: The holy grail of this system would be the suitable for production deployment tag, but no one has figured out how to define it yet. Are crazy ideas welcome in this phase? I start with 2 below: Preface: an idea circulates about visually displaying in a web page the projects.yaml file and the tags in there. Visitors would be able to browse the list of projects and sort, pick, search and find what they need from a nice representation of the 'big tent'. 1) how about we pull the popularity of OpenStack projects as reported in the User Survey and display such number on the page where we list the projects? What if, together with the objective tags managed by TC and community at large, we show also the number of known deployment as guidance? I think we can make this work. Assuming more than N (to my mind 5 or so) deployments report they are using project X, we can say that this is used in production/POC/... and the number of nodes/hypervisors/etc. This makes it concrete and anonymous to avoid the fishing queries. It also allows our community to enter what they are doing in one place rather than answering multiple surveys. I am keen to avoid generic queries such as How many hypervisors are installed for public clouds using Xen but if we have an agreement that 5 avoids company identification, I feel this is feasible. It does help address the maturity question concretely. If it's in prod in 200 deployments, I would consider this to be reasonably mature. If there is only 1, I would worry. I'm not convinced this is a fair metric. What if I tell you, there's just 1 large deployment? or that there's just 1 deployment that has been running the service for quite a bit? It's true that the more deployments there are, the easier it is to trust a project's maturity but I'd be worry about people considering that the only metric and not giving new projects a chance. Flavio [snip] -- @flaper87 Flavio Percoco pgp9Nma0N2AXF.pgp Description: PGP 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] Avoiding regression in project governance
-Original Message- From: Stefano Maffulli [mailto:stef...@openstack.org] Sent: 12 March 2015 00:26 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance On Wed, 2015-03-11 at 17:59 -0500, Ed Leafe wrote: The longer we try to be both sides of this process, the longer we will continue to have these back-and-forths about stability vs. innovation. If I understand correctly your model, it works only for users/operators who decide to rely on a vendor to consume OpenStack. There are quite large enterprises out there who consume directly the code as it's shipped from git.openstack.org, some from trunk others from the stable release .tgz: these guys can't count on companies A, B, C or D to put resources to fix their problems, because they don't talk to those companies. One thing I like of your proposal though, when you say: So what is production-ready? And how would you trust any such designation? I think that it should be the responsibility of groups outside of OpenStack development to make that call. This problem has been bugging the European authorities for a long time and they've invested quite a lot of money to find tools that would help IT managers of the public (and private) sector estimate the quality of open source code. It's a big deal in fact when on one hand you have Microsoft and IBM sales folks selling your IT managers overpriced stuff that just works and on the other hand you have this Linux thing that nobody has heard of, it's gratis and I can find it on the web and many say it just works, too... crazy, right? Well, at the time it was and to some extent, it still is. So the EU has funded lots of research in this area. One group of researcher that I happen to be familiar with, recently has received another bag of Euros and released code/methodologies to evaluate and compare open source projects[1]. The principles they use to evaluate software are not that hard to find and are quite objective. For example: is there a book published about this project? If there is, chances are this project is popular enough for a publisher to sell copies. Is the project's documentation translated in multiple languages? Then we can assume the project is popular. How long has the code been around? How large is the pool of contributors? Are there training programs offered? You get the gist. Following up on my previous crazy ideas (did I hear someone yell keep 'em coming?), probably a set of tags like: book-exists (or book-chapter-exists) specific-training-offered translated-in-1-language (and its bigger brothers translated-in-5, translated-in-10+languages) contributor-size-high (or low, and we can set a rule as we do for the diversity metric used in incubation/graduation) codebase-age-baby, -young and -mature, (in classes, like less than 1, 1-3, 3+ years old) would help a user understand that Nova or Neutron are different from (say) Barbican or Zaqar. These are just statements of facts, not a qualitative assessment of any of the projects mentioned. At the same time, I have the impression these facts would help our users make up their mind. Thoughts? Just one, is it too late to change the name, tag is pretty overloaded and I rather like the sound of badge. I would be nice to see project working towards different new badges and carrying them proudly after earning them. Oh another one, I'm not convinced that 3+ years is still mature project. I think there is room to look bit out of our own sandbox and think where we are in 2, 3 or 5 years time. Perhaps we need to change the governance again, perhaps this could be something that is flexible all the way there, but I would hate to call Nova, Swift, Glance etc. ancient or granny just because they have been around double/triple the mature time. - Erno [1] http://www.ict-prose.eu/2014/12/09/osseval-prose-open-source- evaluation-methodology-and-tool/ __ 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] Avoiding regression in project governance
On 2015-03-10 23:00:16 + (+), Devananda van der Veen wrote: Many of those requirements were subjective (well tested, well documented, etc) and had to be evaluated by the TC. Are these the sort of tags you're referring to? If so, and if the TC delegated responsibility to manage the application of those tags (say, QA team manages the 'well-tested' tag), would that be sufficient? [...] Yep, that's exactly what I'm hoping for. But without those in place yet I worry that we'll end up turning away lots of new requests for help from projects coming forward thinking they're suddenly entitled by virtue of being OpenStack and not really have any common criteria to point them at so that they can work toward getting more priority. -- 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 10:29 AM, Russell Bryant rbry...@redhat.com wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. Thanks, [1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ [2] http://governance.openstack.org/reference/new-projects-requirements.html [3] http://governance.openstack.org/reference/tags/index.html [4] http://governance.openstack.org/reference/incubation-integration-requirements.html -- Russell Bryant __ 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 I think these are great points Russell and agree completely. I'd also say that not only is their risk in rushing approval in the short time, I'd also say that in my opinion there's little or no advantage either. I like the idea of suspending things temporarily until we get the tagging and other details worked out a bit more. Thanks, John __ 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] Avoiding regression in project governance
On Tue, Mar 10, 2015, at 12:46 PM, Doug Hellmann wrote: On Tue, Mar 10, 2015, at 12:29 PM, Russell Bryant wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. I think we made it pretty clear that we would be taking approvals slowly, and that we might not approve any new projects before the summit, precisely for the reasons you state here. I have found the submitted proposals Oops I have found the existing applications useful for thinking about what tags we need, and what other criteria we might be missing (Joe's proposal to add a team employer diversity requirement is one example). Doug Thanks, [1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ [2] http://governance.openstack.org/reference/new-projects-requirements.html [3] http://governance.openstack.org/reference/tags/index.html [4] http://governance.openstack.org/reference/incubation-integration-requirements.html -- Russell Bryant __ 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
Re: [openstack-dev] Avoiding regression in project governance
On Tue, Mar 10, 2015, at 12:29 PM, Russell Bryant wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. I think we made it pretty clear that we would be taking approvals slowly, and that we might not approve any new projects before the summit, precisely for the reasons you state here. I have found the submitted proposals Thanks, [1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ [2] http://governance.openstack.org/reference/new-projects-requirements.html [3] http://governance.openstack.org/reference/tags/index.html [4] http://governance.openstack.org/reference/incubation-integration-requirements.html -- Russell Bryant __ 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
Re: [openstack-dev] Avoiding regression in project governance
Russell Bryant wrote: [...] We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I agree that we need tags to represent the various facets of what was in the integrated release concept. I'm not sure we should block accepting new project teams until all tags are defined, though. That sounds like a way to stall forever. So could you be more specific ? Is there a clear set of tags you'd like to see defined before we add new project teams ? I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. The current plan for the Vancouver Design Summit is to only give space to OpenStack projects (while non-OpenStack projects may get space in ecosystem sessions outside of the Design Summit). So it's only fair for those projects to file for recognition before that happens. -- Thierry Carrez (ttx) __ 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 3:31 PM, James E. Blair cor...@inaugust.com wrote: Joe Gordon joe.gord...@gmail.com writes: After watching the TC meeting, and double checking with the meeting notes [0], it looks like the magnum vote was deferred to next week. But what concerns me is the lack of action items assigned that will help make sure next weeks discussion isn't just a repeat of what happened today. I believe we decided to talk about an application from a project _other_ than Magnum during the next meeting to help us survey the existing applications and identify anything we would like to shore up before we proceed. Then return to Magnum in a later meeting. I think that's important so that if we are going to check ourselves with the new process, that we do it without focusing unduly on Magnum's application, which I think is quite good. So I would like us to see where this thread gets us, whether there is more input to be digested from the ops summit, talk about other applications next week, and then get on to a vote on the Magnum application shortly. Sounds like a good plan to me. To get the ball rolling on the wider discussion I thought I would take a quick look at the 4 applications we have today: Disclaimer: I may be getting some of the details wrong here so take this all with a large grain of salt. 1. python-openstackclient [0] 2. Magnum - OpenStack Containers Service [1] 3. Murano Application Catalog [2] 4.Group Based Policy (GBP) Project [3] First lets consider these projects based on the old model [4] consisting of Scope, Maturity, Process, API, QA, Documentation and Legal. of those items lets look at scope, Maturity, QA. *Scope*: 1. *Yes*. python-openstackclient has a clear scope and and place in OpenStack in fact we already use it all over the place. 2. *Yes*. Magnum definitely doesn't overlap with any existing OpenStack projects (especially nova). I think its safe to say it has a clear scope and is a measured progression of openstack as a whole 3. *Maybe*. Not sure about the scope, it is fairly broad and there may be some open ended corners, such as some references to billing. On the other hand an application catalog sounds really useful and like a measured progression for OpenStack as a whole. Murano may overlap with glance's stated mission of To provide a service where users can upload and discover data assets that are meant to be used with other services, like images for Nova and templates for Heat. Murano also relies heavily on the Mistral service which is still in stackforge itself. 4. *Maybe*. GBP has a clear scope, although a broad and challenging one does not duplicate work and seems like a measured progression. *Maturity*: 1. *Yes*, 6 or so very active reviewers from different companies. No reworks planned 2. *Maybe*. Diverse set of contributors. Major architectural work may be needed to remove single points of failure. Unclear On what the API actually is today, some of it is a management API to provision kubranetes, some is a pass through to kubranetes via the Magnum API (magnum runs 'kubectl create' for you) and some requires using the user using the native kube API. 3. *Maybe* *Yes*. Active team, but not diverse. Not sure about rewrites. Perhaps if there is overlap with other things. 4. *Maybe*. active team, Unclear on if a major rewrite is in its future *QA*: 1. *Yes* 2. *No*. No devstack-gate job set up 3. *Yes* 4. *No*. No devstack-gate job running When looking just these 3 requirements. Only python-openstackclient clearly meets all of them, Magnum and GBP clearly fail the QA requirement. and Murano is up in the air. Now that we have some context of how these would have played out in the old model, lets look at the new requirements [5]. *Aligns with the OpenStack Mission*: Yes to all *4 Opens:* 1. *Yes, *not sure if Dean was formally 'chosen' as PTL but that is easy to sort out 2. *Yes* 3. *Yes, *similar detail about PTL 4. *Yes*, similar detail about PTL *Supports Keystone*: Yes for all *Active team*: Yes to all [0] https://review.openstack.org/#/c/161885/ [1] https://review.openstack.org/#/c/161080/ [2] https://review.openstack.org/#/c/162745/ [3] https://review.openstack.org/#/c/161902/ [4] http://governance.openstack.org/reference/incubation-integration-requirements.html [5] http://governance.openstack.org/reference/new-projects-requirements.html -Jim __ 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
Re: [openstack-dev] Avoiding regression in project governance
Dissolving the integrated release without having a solid plan and replacement is difficult to communicate to people who depend on OpenStack. We’re struggling on that front. That said, I’m still optimistic about project structure reform and think it could be beneficial to the development community and users if it’s executed well. It gives us the opportunity to focus on a tighter core of services that are stable, reliable and scalable, while also recognizing more innovation that’s already happening in the community, beyond the existing integrated release. Coming out of the ops meetup in Philadelphia yesterday, a few things were clear: - Operators don’t want the wild west. They are nervous about dissolving the integrated release, because they want a strong filter and rules - dependency mapping, release timing, test coverage - around the most widely adopted projects. I’m not sure we’re giving them a lot of confidence. - They also want some kind of bar or filter for community projects, to provide guidance beyond it’s in or out of the community. Tags can help with the nuances once they’re in the tent, but I think there’s some support for a bit higher bar overall. - That said, several people expressed they did not want duplication to prevent a project from making it into the tent. They would like to have options beyond the core set of projects - The layers concept came back to play. It was clear there was a distinct dropoff in operators running projects other than nova, keystone, glance, cinder, horizon and neutron - The operators community is keen to help define and apply some tags, especially those relevant to maturity and stability and general operability (I know several of you were at the ops meetup, so please jump in if I’ve missed or misrepresented some of the feedback. Notes from the session https://etherpad.openstack.org/p/PHL-ops-tags.) Based on feedback and conversations yesterday, I think it’s worth evolving the overall project criteria to add 1) a requirement for contributor diversity, 2) some criteria for maturity like documentation, test coverage and integration/dependency requirements, and 3) make sure there are no trademark issues with the project name, since it will be referred to as an OpenStack project. I’m also unclear how we’re planning to refer to these projects, as “Foo, an OpenStack community project” but not “OpenStack Foo? For tags, I think defining a set of projects based on a broad reference architecture / use case like base compute” or “compute kernel” and “object storage” is critical. Those tags will imply the projects share common dependencies and are released together. If we categorize tags that can be applied, compute kernel” could be a higher level category and more prominent. Defining those initial tags should provide enough direction and confidence to start considering new projects. Getting this worked out before the Kilo release would be valuable, because having the “last” integrated release without a clear plan forward creates some real concerns for those running or productizing the software. Not all tags or implementation details need to be defined, of course, but we should be able to communicate a solid plan for the layers and categories of tags, as well as the different bodies who may be involved in defining tags (ops community, etc) before expanding. On Mar 10, 2015, at 2:02 PM, Russell Bryant rbry...@redhat.com wrote: On 03/10/2015 02:56 PM, Thierry Carrez wrote: Russell Bryant wrote: One point of clarification: On 03/10/2015 02:28 PM, Gabriel Hurley wrote: Even more concerning is the sentiment of projects we want to consciously drop from Russell's original email. This was in reference to criteria defined in: http://governance.openstack.org/reference/incubation-integration-requirements.html For example, we previously had a strict requirement *against* duplication of functionality among OpenStack projects unless it was with intent and with a clear plan to replace the old thing. In this new model, that would be a requirement we would consciously drop. It's a requirement we *already* consciously dropped when we approved the new projects requirements. Or do you mean you want to come back on that decision[1]? No, I don't want to come back on it. It was obviously a poorly worded comment. It was an attempt to say that I'd like it if we were closer to having tags that covered most of those requirements, except for the things we no longer care about, such as the example given. -- Russell Bryant __ 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
Re: [openstack-dev] Avoiding regression in project governance
On 03/10/2015 12:29 PM, Russell Bryant wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. The two things are not mutually exclusive. Also, the tags are intended to be informative, not granted by the TC. As Thierry mentioned elsewhere, the job of defining these tags and applying them to projects is a never-ending thing, not something that needs to be completed before allowing new projects into the openstack/ code namespace. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. a) I believe the integrated release moniker held much value previously b) The existing OpenStack projects that were in the integrated release are *already* tagged with the integrated-release tag, and no new projects will be tagged with that. c) There is no connection at all between the bar for projects to get into the openstack/ code namespace and the tags. The tags are informative and can be applied at any time to a project. They are not a blessing by the TC. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Again, tags aren't criteria that we use to determine whether a project is worthy of being in the openstack/ code namespace. The entire point of the Big Tent model was to move away from the TC blessing projects and instead use tags to decorate a project with some useful information. In other words, the point of Big Tent was to decouple these tags from the application process. Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. In contrast, I see no reason to prevent new projects from applying. There's nothing about the new application requirements that mentions tags or the need to tag a project at application time. Best, -jay Thanks, [1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ [2] http://governance.openstack.org/reference/new-projects-requirements.html [3] http://governance.openstack.org/reference/tags/index.html [4] http://governance.openstack.org/reference/incubation-integration-requirements.html __ 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] Avoiding regression in project governance
On 2015-03-10 14:42:18 -0400 (-0400), Russell Bryant wrote: [...] As to specific tags, I refer back to this: http://governance.openstack.org/reference/incubation-integration-requirements.html We worked pretty hard to come up with useful things for projects to aim for. In fact, we considered it a minimum. Let's make sure we capture the things we still value, which I believe is most of it. [...] Coming from a horizontal resource and facilitation perspective, we previously had guidelines like these to help prioritize where effort is focused. I was hoping that most of the incubation requirements would become tags in some form so that support decisions could still be made based on them. Otherwise I worry we're stuck relying on tags which merely declare the set of projects each horizontal team has chosen as a priority (in situations where there are ongoing demands on team members available time to help those specific projects). Yes, horizontal teams should provide the means for OpenStack projects to support themselves where possible, but some activities do not scale linearly and do necessitate hard support decisions. Guidance from the community as to where it's most effective to spend those limited resources is appreciated, and also increases the chances that in those situations the prioritized subset overlaps substantially between various limited resources (which provides a more consistent experience and helps set expectations). -- 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] Avoiding regression in project governance
Russell Bryant wrote: One point of clarification: On 03/10/2015 02:28 PM, Gabriel Hurley wrote: Even more concerning is the sentiment of projects we want to consciously drop from Russell's original email. This was in reference to criteria defined in: http://governance.openstack.org/reference/incubation-integration-requirements.html For example, we previously had a strict requirement *against* duplication of functionality among OpenStack projects unless it was with intent and with a clear plan to replace the old thing. In this new model, that would be a requirement we would consciously drop. It's a requirement we *already* consciously dropped when we approved the new projects requirements. Or do you mean you want to come back on that decision[1]? We can refine those rules as we go and consider applications and realize the rules are incomplete... But denying their existence and ask to freeze until they are defined sounds a bit weird. The rules are there. Slow consideration of additions is the way to make iterative progress, not freezing. [1] http://git.openstack.org/cgit/openstack/governance/commit/?id=fcc4046f7d866d0516f2810571aad0c0ce2cc361 -- Thierry Carrez (ttx) __ 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] Avoiding regression in project governance
Blocking the acceptance of new projects seems punitive and against the spirit of the big tent. Classification (tagging) can be done at any point, and is hardly fixed in stone. You can refine tags as needed. To put it harshly: it is a failure of both leadership and process to have stripped out the old process and set a low bar only to insist that no one may be accepted under the new criteria because you haven't defined the rest of the process yet. Even more concerning is the sentiment of projects we want to consciously drop from Russell's original email. I realize that was meant to apply to whatever becomes the integrated release tag, yet still... the point of the big tent is not to exclude; the big tent is meant to *include and classify* so that the community, operators, distros, and vendors could make the best choices for themselves. So I agree that these projects are a great litmus test for what kind of tags you need, but at this point I don't think you have a leg to stand on for not accepting projects that meet the current criteria. The bar for acceptance is in the governance documents. A freeze seems unjustifiable and dragging your feet seems unnecessary, at least unless you all plan on changing the governance yet again. - Gabriel -Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: Tuesday, March 10, 2015 11:00 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance Russell Bryant wrote: [...] We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I agree that we need tags to represent the various facets of what was in the integrated release concept. I'm not sure we should block accepting new project teams until all tags are defined, though. That sounds like a way to stall forever. So could you be more specific ? Is there a clear set of tags you'd like to see defined before we add new project teams ? I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. The current plan for the Vancouver Design Summit is to only give space to OpenStack projects (while non-OpenStack projects may get space in ecosystem sessions outside of the Design Summit). So it's only fair for those projects to file for recognition before that happens. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] Avoiding regression in project governance
One point of clarification: On 03/10/2015 02:28 PM, Gabriel Hurley wrote: Even more concerning is the sentiment of projects we want to consciously drop from Russell's original email. This was in reference to criteria defined in: http://governance.openstack.org/reference/incubation-integration-requirements.html For example, we previously had a strict requirement *against* duplication of functionality among OpenStack projects unless it was with intent and with a clear plan to replace the old thing. In this new model, that would be a requirement we would consciously drop. -- Russell Bryant __ 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] Avoiding regression in project governance
On 03/10/2015 02:00 PM, Thierry Carrez wrote: Russell Bryant wrote: [...] We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I agree that we need tags to represent the various facets of what was in the integrated release concept. I'm not sure we should block accepting new project teams until all tags are defined, though. That sounds like a way to stall forever. So could you be more specific ? Is there a clear set of tags you'd like to see defined before we add new project teams ? I'd like to have enough tags that I don't feel like we're communicating drastically less about the state of OpenStack projects. Approving now means we'll have a big pool of projects with absolutely no attempt to communicate anything useful about the difference between Nova, Swift, and the newest experiment. I'd rather feel like we've replaced one thing with something that's improvement. Today feels like we've replaced something with close to nothing, which seems like the worst time to open the gates for new projects. As to specific tags, I refer back to this: http://governance.openstack.org/reference/incubation-integration-requirements.html We worked pretty hard to come up with useful things for projects to aim for. In fact, we considered it a minimum. Let's make sure we capture the things we still value, which I believe is most of it. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. The current plan for the Vancouver Design Summit is to only give space to OpenStack projects (while non-OpenStack projects may get space in ecosystem sessions outside of the Design Summit). So it's only fair for those projects to file for recognition before that happens. I hear you. That's a real problem that must be dealt with. I don't think it's justification for governance change, though. If nothing else, the TC could just make a list of the projects we're willing to give space to given our collective view of their momentum in the community. We're elected to make decisions with a broad view like that after all. -- Russell Bryant __ 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] Avoiding regression in project governance
On 10/03/15 12:29, Russell Bryant wrote: I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved*any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. I appreciate the concerns here, but I'm also uncomfortable with having an open-ended hold on making projects an official part of OpenStack. There are a lot of projects on StackForge that are by any reasonable definition a part of this community, it seems wrong to put them on indefinite hold when the Big Tent model has already been agreed upon. Here is a possible compromise: invite applications now and set a fixed date on which the new system will become operational. That way it's the TC's responsibility to get the house in order by the deadline, rather than making it everyone else's problem. If we see a wildly inappropriate application then that's valuable data about where the requirements are unclear. To avoid mass confusion in the absence of a mature set of tags, I think it's probably appropriate that the changes kick in after the Kilo release, but let's make it as soon as possible after that. 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 9:29 AM, Russell Bryant rbry...@redhat.com wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved *any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. I don't follow this argument. My understanding is no tags will be required to join 'OpenStack,' they are just optional things for projects to try to achieve once they are in. So holding off accepting new projects for something that is not required during the adding new projects process seems odd. Perhaps a better way to say the same thing is: While working with the tagging system to come up with a good set of tags to represent our previous graduation requirements, we may want to adjust the new project requirements[0]. [0] governance.openstack.org/reference/new-projects-requirements.html The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. I fear this is a real possibility, and sounds like a reason to proceed carefully with adding new projects. Thanks, [1] http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ [2] http://governance.openstack.org/reference/new-projects-requirements.html [3] http://governance.openstack.org/reference/tags/index.html [4] http://governance.openstack.org/reference/incubation-integration-requirements.html -- Russell Bryant __ 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
Re: [openstack-dev] Avoiding regression in project governance
On 03/10/2015 02:43 PM, Thierry Carrez wrote: Joe Gordon wrote: On Tue, Mar 10, 2015 at 9:29 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com wrote: We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. I don't follow this argument. My understanding is no tags will be required to join 'OpenStack,' they are just optional things for projects to try to achieve once they are in. So holding off accepting new projects for something that is not required during the adding new projects process seems odd. Perhaps a better way to say the same thing is: While working with the tagging system to come up with a good set of tags to represent our previous graduation requirements, we may want to adjust the new project requirements[0]. [0] governance.openstack.org/reference/new-projects-requirements.html http://governance.openstack.org/reference/new-projects-requirements.html I totally agree with you. Project team additions are judged on the new projects requirements. Tagging are just about describing them once they are in. I suspect most people advocating for a freeze are actually wanting extra rules to be added to the new project requirements (think: diversity). We said at the TC that we would refine those requirements as we go and learn... So slowly processing applications sounds like a better way to make fast iterative progress than freezing altogether. I completely understand and agree with the difference between project additions and the categorization. I /think/ Russell's point is that we'd end up adding not-yet-categorized stuff in the tent and that might create temporary confusion -- I tend to think that freezing project addition is actually more detrimental. Yes, that was my point. It's an ordering issue. -- Russell Bryant __ 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] Avoiding regression in project governance
On 03/10/2015 02:56 PM, Thierry Carrez wrote: Russell Bryant wrote: One point of clarification: On 03/10/2015 02:28 PM, Gabriel Hurley wrote: Even more concerning is the sentiment of projects we want to consciously drop from Russell's original email. This was in reference to criteria defined in: http://governance.openstack.org/reference/incubation-integration-requirements.html For example, we previously had a strict requirement *against* duplication of functionality among OpenStack projects unless it was with intent and with a clear plan to replace the old thing. In this new model, that would be a requirement we would consciously drop. It's a requirement we *already* consciously dropped when we approved the new projects requirements. Or do you mean you want to come back on that decision[1]? No, I don't want to come back on it. It was obviously a poorly worded comment. It was an attempt to say that I'd like it if we were closer to having tags that covered most of those requirements, except for the things we no longer care about, such as the example given. -- Russell Bryant __ 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 1:32 PM, Jay Pipes jaypi...@gmail.com wrote: On 03/10/2015 02:28 PM, Gabriel Hurley wrote: Blocking the acceptance of new projects seems punitive and against the spirit of the big tent. Classification (tagging) can be done at any point, and is hardly fixed in stone. You can refine tags as needed. To put it harshly: it is a failure of both leadership and process to have stripped out the old process and set a low bar only to insist that no one may be accepted under the new criteria because you haven't defined the rest of the process yet. Even more concerning is the sentiment of projects we want to consciously drop from Russell's original email. I realize that was meant to apply to whatever becomes the integrated release tag, yet still... the point of the big tent is not to exclude; the big tent is meant to *include and classify* so that the community, operators, distros, and vendors could make the best choices for themselves. So I agree that these projects are a great litmus test for what kind of tags you need, but at this point I don't think you have a leg to stand on for not accepting projects that meet the current criteria. The bar for acceptance is in the governance documents. A freeze seems unjustifiable and dragging your feet seems unnecessary, at least unless you all plan on changing the governance yet again. Amen. +1. To be honest, given how OpenStack is always about change, I'm confused that people are not willing to stop, evaluate where we are, and make sure it's moving in the intended direction. Seems like taking stock of where we as we change the governance model would be a wise thing to do. As a given example, I'd like to compare the governance model OpenStack used to have with the one OpenDaylight currently has. OpenStack is moving towards the ODL model with the big tent proposal. The existing ODL governance model has been to accept anything that is proposed (note: that's the tl;dr version, read here [1] for more details). Any project proposed in ODL is accepted and allowed in. Great, right? Except it's not always great, because there is no check for overlapping functionality, they allow in vendor-only projects, and they now have 48 accepted projects. Even worse, at least 5 of those implement network virtualization. As a user of ODL, trying to figure out which one to use for network virtualization is challenging. Someone used the reference of ODL being a bag of parts you assemble on your own, and to some extent that's true. Maybe this is a distribution's job, in which case the bag of parts reference for upstream may be ok. It is what it is, after all. Even worse, when you want to do something like integrate ODL with OpenStack, which network virtualization project do you use? It depends on who you work for or which project you're involved in. But the answer is never a consensus one, because with overlapping functionality, integrating ODL and OpenStack now means different things to different people. At the end of the day, it's my opinion consensus is the part of the Big Tent that worries me. To me, consensus is a big part of what makes OpenStack awesome. However tags and big tents evolve, if we lose that, we've lost part of OpenStack that got us to where we are. Kyle [1] https://wiki.opendaylight.org/view/Project_Proposals:Main -jay - Gabriel -Original Message- From: Thierry Carrez [mailto:thie...@openstack.org] Sent: Tuesday, March 10, 2015 11:00 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Avoiding regression in project governance Russell Bryant wrote: [...] We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. The resulting set of tags doesn't have to be focused on replicating our previous set of criteria. The focus must be on what information is needed by various groups of consumers and tags are a mechanism to implement that. In any case, we're far from that point because today we have nothing. I agree that we need tags to represent the various facets of what was in the integrated release concept. I'm not sure we should block accepting new project teams until all tags are defined, though. That sounds like a way to stall forever. So could you be more specific ? Is there a clear set of tags you'd like to see defined before we add new project teams ? I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need
Re: [openstack-dev] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 12:30 PM, Zane Bitter zbit...@redhat.com wrote: On 10/03/15 12:29, Russell Bryant wrote: I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved*any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. I appreciate the concerns here, but I'm also uncomfortable with having an open-ended hold on making projects an official part of OpenStack. There are a lot of projects on StackForge that are by any reasonable definition a part of this community, it seems wrong to put them on indefinite hold when the Big Tent model has already been agreed upon. Here is a possible compromise: invite applications now and set a fixed date on which the new system will become operational. That way it's the TC's responsibility to get the house in order by the deadline, rather than making it everyone else's problem. If we see a wildly inappropriate application then that's valuable data about where the requirements are unclear. To avoid mass confusion in the absence of a mature set of tags, I think it's probably appropriate that the changes kick in after the Kilo release, but let's make it as soon as possible after that. After watching the TC meeting, and double checking with the meeting notes [0], it looks like the magnum vote was deferred to next week. But what concerns me is the lack of action items assigned that will help make sure next weeks discussion isn't just a repeat of what happened today. I get that starting to apply the big tent model to admit new projects will take time to get right, but deferring a decision for a it's not you, it's me reason without any actionable items doesn't sound like real progress to me. [0] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-03-10-20.06.html 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 __ 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] Avoiding regression in project governance
On Tue, Mar 10, 2015, at 05:27 PM, Joe Gordon wrote: On Tue, Mar 10, 2015 at 12:30 PM, Zane Bitter zbit...@redhat.com wrote: On 10/03/15 12:29, Russell Bryant wrote: I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved*any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. I appreciate the concerns here, but I'm also uncomfortable with having an open-ended hold on making projects an official part of OpenStack. There are a lot of projects on StackForge that are by any reasonable definition a part of this community, it seems wrong to put them on indefinite hold when the Big Tent model has already been agreed upon. Here is a possible compromise: invite applications now and set a fixed date on which the new system will become operational. That way it's the TC's responsibility to get the house in order by the deadline, rather than making it everyone else's problem. If we see a wildly inappropriate application then that's valuable data about where the requirements are unclear. To avoid mass confusion in the absence of a mature set of tags, I think it's probably appropriate that the changes kick in after the Kilo release, but let's make it as soon as possible after that. After watching the TC meeting, and double checking with the meeting notes [0], it looks like the magnum vote was deferred to next week. But what concerns me is the lack of action items assigned that will help make sure next weeks discussion isn't just a repeat of what happened today. I get that starting to apply the big tent model to admit new projects will take time to get right, but deferring a decision for a it's not you, it's me reason without any actionable items doesn't sound like real progress to me. I came away with a very different impression. I thought we agreed that some of the folks who want more tags would start working on proposing them. We also have several proposals for projects that came in too late to be considered this week that we need to read and understand. We will then use all of that information together to decide if we are comfortable that we have the right sorts of guidelines in place, or if we need more (such as your proposal on diversity). So while there were no person X go do Y assignments, we do all have work that we're going to be doing over the next week to prepare to discuss the issue again. Doug [0] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-03-10-20.06.html 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 __ 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
Re: [openstack-dev] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 3:00 PM, Doug Hellmann d...@doughellmann.com wrote: On Tue, Mar 10, 2015, at 05:27 PM, Joe Gordon wrote: On Tue, Mar 10, 2015 at 12:30 PM, Zane Bitter zbit...@redhat.com wrote: On 10/03/15 12:29, Russell Bryant wrote: I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved*any* tags other than the one that reflects which projects are included in the final integrated release (Kilo) [3]. Despite the previously discussed challenges with the integrated release, it did at least mean that a project has met a very useful set of criteria [4]. We now have several new project proposals. However, I propose not approving any new projects until we have a tagging system that is at least far enough along to represent the set of criteria that we used to apply to all OpenStack projects (with exception for ones we want to consciously drop). Otherwise, I think it's a significant setback to our project governance as we have yet to provide any useful way to navigate the growing set of projects. I appreciate the concerns here, but I'm also uncomfortable with having an open-ended hold on making projects an official part of OpenStack. There are a lot of projects on StackForge that are by any reasonable definition a part of this community, it seems wrong to put them on indefinite hold when the Big Tent model has already been agreed upon. Here is a possible compromise: invite applications now and set a fixed date on which the new system will become operational. That way it's the TC's responsibility to get the house in order by the deadline, rather than making it everyone else's problem. If we see a wildly inappropriate application then that's valuable data about where the requirements are unclear. To avoid mass confusion in the absence of a mature set of tags, I think it's probably appropriate that the changes kick in after the Kilo release, but let's make it as soon as possible after that. After watching the TC meeting, and double checking with the meeting notes [0], it looks like the magnum vote was deferred to next week. But what concerns me is the lack of action items assigned that will help make sure next weeks discussion isn't just a repeat of what happened today. I get that starting to apply the big tent model to admit new projects will take time to get right, but deferring a decision for a it's not you, it's me reason without any actionable items doesn't sound like real progress to me. I came away with a very different impression. I thought we agreed that some of the folks who want more tags would start working on proposing them. We also have several proposals for projects that came in too late to be considered this week that we need to read and understand. We will then use all of that information together to decide if we are comfortable that we have the right sorts of guidelines in place, or if we need more (such as your proposal on diversity). So while there were no person X go do Y assignments, we do all have work that we're going to be doing over the next week to prepare to discuss the issue again. Sure I did see some of that in the meeting, but the minutes have literally no action items. And given our previous record for proposing and discussing new tags, etc. without clear action items I am somewhat doubtful about next week being different. Doug [0] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-03-10-20.06.html 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 __ 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 __ 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] Avoiding regression in project governance
Russell Bryant rbry...@redhat.com writes: Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrated release with a set of tags. A project would be given a tag if it meets some defined set of criteria. ... I can't think of any good reason to rush into approving projects in the short term. If we're not able to work out this rich tagging system in a reasonable amount of time, then maybe the whole approach is broken and we need to rethink the whole approach. I agree that we should not rush into things if we are not ready. However, I do think we can proceed carefully with new applications. I believe that the new project requirements as currently written adequately express the desire in our community to be inclusive of new projects and have a low barrier for entry into the community. It removes quite a bit of process overhead and TC bottlenecks. I'm particularly enthused that it helps projects grow up as part of the OpenStack community instead of demanding that they show up fully-formed. I agree that this will create a sea of projects that will be hard to navigate. We knew that, and to some extent, that is part of the intent. The next step, as is pointed out, is that we need tools to help navigate. For the moment, our idea for that is tags (while we had a serious conversation about whether they are needed at all, we are still proceeding with them). The holy grail of this system would be the suitable for production deployment tag, but no one has figured out how to define it yet. In the mean time, many of the things that are coming up could very easily be described automatically (by tags or otherwise) -- contributor diversity, community size, development history, etc. We should note these and start the process of surfacing those criteria where useful. But all is not lost -- we do have one tag already -- the current integrated release, and it's not going anywhere just yet. I think we can start to approve new projects, begin to describe them in ways that make sense as we see what would be helpful, and rely on the existing list of integrated projects as our signal of what is most important right now. -Jim __ 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] Avoiding regression in project governance
Joe Gordon joe.gord...@gmail.com writes: After watching the TC meeting, and double checking with the meeting notes [0], it looks like the magnum vote was deferred to next week. But what concerns me is the lack of action items assigned that will help make sure next weeks discussion isn't just a repeat of what happened today. I believe we decided to talk about an application from a project _other_ than Magnum during the next meeting to help us survey the existing applications and identify anything we would like to shore up before we proceed. Then return to Magnum in a later meeting. I think that's important so that if we are going to check ourselves with the new process, that we do it without focusing unduly on Magnum's application, which I think is quite good. So I would like us to see where this thread gets us, whether there is more input to be digested from the ops summit, talk about other applications next week, and then get on to a vote on the Magnum application shortly. -Jim __ 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 12:12 PM Lauren Sell lau...@openstack.org wrote: Dissolving the integrated release without having a solid plan and replacement is difficult to communicate to people who depend on OpenStack. We’re struggling on that front. That said, I’m still optimistic about project structure reform and think it could be beneficial to the development community and users if it’s executed well. It gives us the opportunity to focus on a tighter core of services that are stable, reliable and scalable, while also recognizing more innovation that’s already happening in the community, beyond the existing integrated release. Coming out of the ops meetup in Philadelphia yesterday, a few things were clear: - Operators don’t want the wild west. They are nervous about dissolving the integrated release, because they want a strong filter and rules - dependency mapping, release timing, test coverage - around the most widely adopted projects. I’m not sure we’re giving them a lot of confidence. We're not lowering the testing standards of existing projects... can you be more clear as to what is creating this concern? - They also want some kind of bar or filter for community projects, to provide guidance beyond it’s in or out of the community. Tags can help with the nuances once they’re in the tent, but I think there’s some support for a bit higher bar overall. What would that bar look like? If what we have in new-project-requirements isn't enough, what changes are being suggested? - That said, several people expressed they did not want duplication to prevent a project from making it into the tent. They would like to have options beyond the core set of projects Glad to hear that. - The layers concept came back to play. It was clear there was a distinct dropoff in operators running projects other than nova, keystone, glance, cinder, horizon and neutron Not surprising - The operators community is keen to help define and apply some tags, especially those relevant to maturity and stability and general operability (I know several of you were at the ops meetup, so please jump in if I’ve missed or misrepresented some of the feedback. Notes from the session https://etherpad.openstack.org/p/PHL-ops-tags.) Based on feedback and conversations yesterday, I think it’s worth evolving the overall project criteria to add 1) a requirement for contributor diversity, Joe's got a proposal up for that already. 2) some criteria for maturity like documentation, test coverage and integration/dependency requirements, I don't think that should be a requirement for entry -- after all, these are still subjective judgements, subject to invalidation over time -- but I would like to see metadata (ie, tags) that describe a projects' current state, and can be updated by the community. and 3) make sure there are no trademark issues with the project name, since it will be referred to as an OpenStack project. I’m also unclear how we’re planning to refer to these projects, as “Foo, an OpenStack community project” but not “OpenStack Foo? That's a good question For tags, I think defining a set of projects based on a broad reference architecture / use case like base compute” or “compute kernel” and “object storage” is critical. Those tags will imply the projects share common dependencies and are released together. If we categorize tags that can be applied, compute kernel” could be a higher level category and more prominent. Defining those initial tags should provide enough direction and confidence to start considering new projects. I've started drafting some tags for layers or use cases -- I'm sure they'll get expanded on. I'll post a link once I've uploaded to gerrit. -- Devananda __ 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] Avoiding regression in project governance
On Tue, Mar 10, 2015 at 12:00 PM Jeremy Stanley fu...@yuggoth.org wrote: On 2015-03-10 14:42:18 -0400 (-0400), Russell Bryant wrote: [...] As to specific tags, I refer back to this: http://governance.openstack.org/reference/incubation- integration-requirements.html We worked pretty hard to come up with useful things for projects to aim for. In fact, we considered it a minimum. Let's make sure we capture the things we still value, which I believe is most of it. [...] Coming from a horizontal resource and facilitation perspective, we previously had guidelines like these to help prioritize where effort is focused. I was hoping that most of the incubation requirements would become tags in some form so that support decisions could still be made based on them. Many of those requirements were subjective (well tested, well documented, etc) and had to be evaluated by the TC. Are these the sort of tags you're referring to? If so, and if the TC delegated responsibility to manage the application of those tags (say, QA team manages the 'well-tested' tag), would that be sufficient? If not, which ones do you mean? Otherwise I worry we're stuck relying on tags which merely declare the set of projects each horizontal team has chosen as a priority (in situations where there are ongoing demands on team members available time to help those specific projects). These would be much more objective tags (eg, qa-supported' or 'infra-supported') ... but I see your point that this doesn't help inform decisions that horizontal teams need to make, it merely reflects the ones that have already been made. Nothing says we can't have both sets of tags ... but so far, neither has been proposed. Yes, horizontal teams should provide the means for OpenStack projects to support themselves where possible, but some activities do not scale linearly and do necessitate hard support decisions. Guidance from the community as to where it's most effective to spend those limited resources is appreciated, and also increases the chances that in those situations the prioritized subset overlaps substantially between various limited resources (which provides a more consistent experience and helps set expectations). This is in line with my view -- tags should not serve as governance in the rule-setting sense, but as providing guidance to the community. Guidance as to what sort of behavior is expected // accepted, and guidance as to the status of each project's conformity to those expectations. Wit this, we can, collectively, make more informed decisions, without being expected to independently gather that information and come to the same conclusions. -Devananda __ 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
