Re: [openstack-dev] [all][tc] governance changes for big tent model
As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Thanks Doug for moving this discussion out of the blogosphere and into gerrit. That will be very helpful in driving the discussion forward. However, given the proximity of the TC elections, should these all patches all be workflow -1'd as WIP to ensure nothing lands before the incoming TC is ratified? (I'm assuming here that the decision-making on these fairly radical proposals should rest with the new post-election TC - is that a correct assumption?) Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
Eoghan Glynn wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Thanks Doug for moving this discussion out of the blogosphere and into gerrit. That will be very helpful in driving the discussion forward. However, given the proximity of the TC elections, should these all patches all be workflow -1'd as WIP to ensure nothing lands before the incoming TC is ratified? (I'm assuming here that the decision-making on these fairly radical proposals should rest with the new post-election TC - is that a correct assumption?) Yes, those would be voted on by the kilo-membership of the TC. If the current membership decides to meet during the election season, it will be to discuss/brainstorm things, not to finalize or vote on them. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Oct 3, 2014, at 7:13 AM, Eoghan Glynn egl...@redhat.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Thanks Doug for moving this discussion out of the blogosphere and into gerrit. That will be very helpful in driving the discussion forward. However, given the proximity of the TC elections, should these all patches all be workflow -1'd as WIP to ensure nothing lands before the incoming TC is ratified? (I'm assuming here that the decision-making on these fairly radical proposals should rest with the new post-election TC - is that a correct assumption?) Yes, this is absolutely meant to be voted on at some point after the election. My goal was to turn the blog posts into specific changes to our current policies, in part so we could understand the gaps in what people are saying in more abstract terms elsewhere. Doug Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. Doug [1] https://review.openstack.org/#/c/125785/2/reference/project-testing-policies.rst [2] https://review.openstack.org/#/c/125789/ -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Oct 3, 2014, at 9:02 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 7:13 AM, Eoghan Glynn egl...@redhat.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Thanks Doug for moving this discussion out of the blogosphere and into gerrit. That will be very helpful in driving the discussion forward. However, given the proximity of the TC elections, should these all patches all be workflow -1'd as WIP to ensure nothing lands before the incoming TC is ratified? (I'm assuming here that the decision-making on these fairly radical proposals should rest with the new post-election TC - is that a correct assumption?) Yes, this is absolutely meant to be voted on at some point after the election. My goal was to turn the blog posts into specific changes to our current policies, in part so we could understand the gaps in what people are saying in more abstract terms elsewhere. It also looks like one of the early changes will need to be rebased before it can merge. Rather than lose the discussion context, I will wait as long as possible to do that, so please continue commenting on the current draft. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) I need to either get over that or decide what parts need tweaking for docs and support optimization. I'll get going on reviews -- thanks a bunch for all this compilation and for the good blog writing. Much appreciated. Anne Doug [1] https://review.openstack.org/#/c/125785/2/reference/project-testing-policies.rst [2] https://review.openstack.org/#/c/125789/ -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On 10/03/2014 09:25 AM, Anne Gentle wrote: On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann d...@doughellmann.com mailto:d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com mailto:devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com mailto:d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) I need to either get over that or decide what parts need tweaking for docs and support optimization. I'll get going on reviews -- thanks a bunch for all this compilation and for the good blog writing. Much appreciated. The relationships are also quite important for deployment units, because we're talking about what minimal set of things we're going to say work together. And we're going to be dictating the minimum lock step upgrade unit. Any project that fully stands on it's own (like Swift or Ironic, given that keystone is optional) can be stood up on their own. Ok, they go in one bucket and you call tell people, you want this function, just install this project, it's a vertical on it's own. Heat works quite well against a compute stack you don't run yourself (teams doing this in HP all the time). I expect Zaqar to be like Swift, and be a thing you can just have. That's not the case for the compute stack, for better or worse. And, based on the User Surveys, the compute stack is what most people are trying to get out of OpenStack right now. So we should unconfuse that, create a smaller basic building block (that people can understand), and provide guidance on how you could expand your function with our vast array of great expansion sets. OpenStack is enough parts that you can mix and match as much as you want, but much like the 600 config options in Nova, we really can't document every combination of things. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, 3 Oct 2014, Anne Gentle wrote: I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) Yes, +many. In my reading it seems like we are trying to optimize the process for developers which is exactly the opposite of what we want to be doing if we want to address the perceived quality problems that we see. We should be optimizing for the various user groups (which, I admit, have been identified pretty well in some of the blog posts). This would, of course, mean enhancing the docs (and other cross project) process... At the moment we're trying to create governance structures that incrementally improve the existing model for how development is being done. I think we should consider more radical changes, changes which allow us to work on what users want: an OpenStack that works. To do that I think we need to figure out two things: * how to fail faster * how to stop thinking of ourselves as being on particular projects I got hired to work on telemetry, but I've managed to do most of my work in QA related things because what's the point of making new stuff if you can't test it reliably? What I'd really like to say my job is is making OpenStack the best it possibly can be. If we keep focusing on the various services as entangled but separate and competing interests rather than on how to make OpenStack good, we're missing the point and the boat. Our job as developers is to make things easier (or at least possible) for the people who use the stuff we build. Naturally we want to make that as frictionless as possible, but not at the cost of the people's ease. There are many perverse incentives in OpenStack's culture which encourage people to hoard. For example it is useful to keep code in one's own team's repository because the BPs, reviews and bugs which reflect on that repository reflect on the value of the team. Who is that good for? So much of the talk is about trying to figure out how to make the gate more resilient. No! How about we listen to what the gate is telling us: Our code is full of race conditions, a memory pig, poorly defined contracts, and just downright tediously slow and heavy. And _fix that_. What I think we need to do to improve is enhance the granularity at which someone can participate. Smaller repos, smaller teams, cleaner boundaries between things. Disconnected (and rolling) release cycles. Achieve fail fast by testing in (much) smaller lumps before code ever reaches the global CI. You know: make better tests locally that confirm good boundaries. Don't run integration tests until the unit, pep8 and in-tree functional tests have passed. If there is a failure: exit! FAIL! Don't run all the rest of the tests uselessly. We need to not conflate the code and its structure with the structure of our governance. We need to put responsibility for the quality of the code on to the people who make it, not big infra. We need to make it easier for people to participate in that quality making. And most importantly we need to make sure the users are driving what we do and we need to make it far easier for them to do that driving. Obviously there are many more issues than these, but I think some of the above is being left out of the discussion, and this message needs to stop. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, 3 Oct 2014, Sean Dague wrote: OpenStack is enough parts that you can mix and match as much as you want, but much like the 600 config options in Nova, we really can't document every combination of things. People seem to talk about this flexibility as if it were a good thing. It's not. There's tyranny of choice all over OpenStack. Is that good for real people or just large players and our corporate hosts? -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Oct 3, 2014, at 9:25 AM, Anne Gentle a...@openstack.org wrote: On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) Yes, that’s a gap in what has been proposed. There is some discussion about addressing cross-project teams more fully on https://review.openstack.org/#/c/125789/ and I agree we need to be more explicit about our intent, both in saying which cross-project teams are official and what that means to the other teams. Doug I need to either get over that or decide what parts need tweaking for docs and support optimization. I'll get going on reviews -- thanks a bunch for all this compilation and for the good blog writing. Much appreciated. Anne Doug [1] https://review.openstack.org/#/c/125785/2/reference/project-testing-policies.rst [2] https://review.openstack.org/#/c/125789/ -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, Oct 3, 2014 at 9:32 AM, Chris Dent chd...@redhat.com wrote: People seem to talk about this flexibility as if it were a good thing. It's not. There's tyranny of choice all over OpenStack. Is that good for real people or just large players and our corporate hosts? + We have a history of trying to be all things to all people, and our structure makes saying no hard and unpopular. It appears as though competitors with checkbooks are saying no to each other, not that technical leaders are saying yes to good projects and implementations that have technical merit. I believe that part of the all-things model is due to our Corporate structure which has the notion that they all have to differentiate their cloud from the others. For more on how that is working out see DefCore, et al. At the technical level we like to say we are beyond that, and I believe that many really are. But many is not all and the results are clearly not acceptable because where we are having this conversation... dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On 10/03/2014 10:06 AM, Chris Dent wrote: On Fri, 3 Oct 2014, Anne Gentle wrote: I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) Yes, +many. plus infinity. In my reading it seems like we are trying to optimize the process for developers which is exactly the opposite of what we want to be doing if we want to address the perceived quality problems that we see. We should be optimizing for the various user groups (which, I admit, have been identified pretty well in some of the blog posts). Precisely. This would, of course, mean enhancing the docs (and other cross project) process... Yep! This is something I harped on quite a bit in my second blog post. At the moment we're trying to create governance structures that incrementally improve the existing model for how development is being done. I think we should consider more radical changes, changes which allow us to work on what users want: an OpenStack that works. Yay! To do that I think we need to figure out two things: * how to fail faster * how to stop thinking of ourselves as being on particular projects More yay! I got hired to work on telemetry, but I've managed to do most of my work in QA related things because what's the point of making new stuff if you can't test it reliably? What I'd really like to say my job is is making OpenStack the best it possibly can be. If we keep focusing on the various services as entangled but separate and competing interests rather than on how to make OpenStack good, we're missing the point and the boat. Our job as developers is to make things easier (or at least possible) for the people who use the stuff we build. Naturally we want to make that as frictionless as possible, but not at the cost of the people's ease. There are many perverse incentives in OpenStack's culture which encourage people to hoard. For example it is useful to keep code in one's own team's repository because the BPs, reviews and bugs which reflect on that repository reflect on the value of the team. Who is that good for? So much of the talk is about trying to figure out how to make the gate more resilient. No! How about we listen to what the gate is telling us: Our code is full of race conditions, a memory pig, poorly defined contracts, and just downright tediously slow and heavy. And _fix that_. I think it's important to discuss both things: the gate structure (and various inefficiencies the gate *policies* create within the system) as well as the fragility and design of the code bases themselves. What I think we need to do to improve is enhance the granularity at which someone can participate. Smaller repos, smaller teams, cleaner boundaries between things. Disconnected (and rolling) release cycles. Achieve fail fast by testing in (much) smaller lumps before code ever reaches the global CI. You know: make better tests locally that confirm good boundaries. Don't run integration tests until the unit, pep8 and in-tree functional tests have passed. If there is a failure: exit! FAIL! Don't run all the rest of the tests uselessly. Yup, ++. We need to not conflate the code and its structure with the structure of our governance. We need to put responsibility for the quality of the code on to the people who make it, not big infra. We need to make it easier for people to participate in that quality making. And most importantly we need to make sure the users are driving what we do and we need to make it far easier for them to do that driving. Obviously there are many more issues than these, but I think some of the above is being left out of the discussion, and this message needs to stop. Amen, brother. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I agree the relationships are very important for gate structure and less so for governance. I thought it would be nice to codify the relationships in a machine readable format so we can do things with it, like try making different rules and see how they would work. For example we can already make two groups of things that may be useful for testing: * services that nothing depends on * services that don't depend on other services Latest graph: http://i.imgur.com/y8zmNIM.png Doug [1] https://review.openstack.org/#/c/125785/2/reference/project-testing-policies.rst [2] https://review.openstack.org/#/c/125789/ -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
- Original Message - On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I agree the relationships are very important for gate structure and less so for governance. I thought it would be nice to codify the relationships in a machine readable format so we can do things with it, like try making different rules and see how they would work. For example we can already make two groups of things that may be useful for testing: * services that nothing depends on * services that don't depend on other services Latest graph: http://i.imgur.com/y8zmNIM.png This diagram is missing any relationships for ceilometer. Ceilometer calls APIs provided by: * keystone * nova * glance * neutron * swift Ceilometer consumes notifications from: * keystone * nova * glance * neutron * cinder * ironic * heat * sahara Ceilometer serves incoming API calls from: * heat * horizon Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, Oct 3, 2014 at 9:42 AM, Eoghan Glynn egl...@redhat.com wrote: - Original Message - On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I agree the relationships are very important for gate structure and less so for governance. I thought it would be nice to codify the relationships in a machine readable format so we can do things with it, like try making different rules and see how they would work. For example we can already make two groups of things that may be useful for testing: * services that nothing depends on * services that don't depend on other services Latest graph: http://i.imgur.com/y8zmNIM.png This diagram is missing any relationships for ceilometer. It sure is, the graph is very much a work in progress. Here is the yaml that generates it https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml want to update that to includes ceilometer's relationships? Ceilometer calls APIs provided by: * keystone * nova * glance * neutron * swift Ceilometer consumes notifications from: * keystone * nova * glance * neutron * cinder * ironic * heat * sahara Ceilometer serves incoming API calls from: * heat * horizon Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Oct 3, 2014, at 12:26 PM, Joe Gordon joe.gord...@gmail.com wrote: On Fri, Oct 3, 2014 at 6:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I agree the relationships are very important for gate structure and less so for governance. I thought it would be nice to codify the relationships in a machine readable format so we can do things with it, like try making different rules and see how they would work. For example we can already make two groups of things that may be useful for testing: * services that nothing depends on * services that don't depend on other services Latest graph: http://i.imgur.com/y8zmNIM.png Absolutely. I love these sorts of dependency graphs, and used them extensively when working out library relationships before we started graduations in juno. Doug Doug [1] https://review.openstack.org/#/c/125785/2/reference/project-testing-policies.rst [2] https://review.openstack.org/#/c/125789/ -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, Oct 3, 2014 at 6:25 AM, Anne Gentle a...@openstack.org wrote: On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) I need to either get over that or decide what parts need tweaking for docs and support optimization. I'll get going on reviews -- thanks a bunch for all this compilation and for the good blog writing. Much appreciated. Actually, while it looks like we're optimizing for dev, I'm not sure that's actually what we're doing. But also, the patches Doug proposed didn't capture several things I'm thinking about, so it's possible no one else knows that yet. I've commented in gerrit, but I'll try to also clarify it a bit here. == (copying some comments from https://review.openstack.org/#/c/125787/2 ) I expressly do NOT want official project/team status to in any way indicate that the horizontal teams (docs, qa, etc) suddenly need to start supporting those projects. That will not scale, as we're already seeing. I believe we need to let in lots of code and lots of teams of people who produce such code into the big tent of OpenStack, without burgeoning the Integrated Release by cogating all of that, or requiring the horizontal-scaling-efforts (docs, qa, etc) to take responsibility for them, and also without indicating (whether explicitly or implicitly) that those teams are The One True Way within our community to do the thing they do. == How does this relate to the gate structure changes that Monty and I came up with two days ago? When a change in one project breaks another project, because of poorly defined API contracts, non-documented expected behaviors, and so on, which we see all the time today, it's because we (developers) are hitting some of the same problems that our users would hit when they use these services. Right now, we're co-gating everything, so we are able to gloss over these problems (to a degree, but not entirely). It will be somewhat painful when we stop doing that. Projects will land changes that break other projects' gates, which is not OK, and we'll realize where a lot of unintended / undocumented inter-dependencies are, and we'll have to make stable APIs around that. I think this is actually very closely in line with what Jay's been proposing as well (though I'm not yet sold on the tags part). -Deva ___ OpenStack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, Oct 3, 2014 at 6:47 AM, Sean Dague s...@dague.net wrote: On 10/03/2014 09:25 AM, Anne Gentle wrote: On Fri, Oct 3, 2014 at 8:07 AM, Doug Hellmann d...@doughellmann.com mailto:d...@doughellmann.com wrote: On Oct 3, 2014, at 12:46 AM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com mailto:devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com mailto:d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). The relationships are very important for setting up an optimal gate structure. I’m less convinced they are important for setting up the governance structure, and I do not think we want a specific gate configuration embedded in the governance structure at all. That’s why I’ve tried to describe general relationships (“optional inter-project dependences” vs. “strict co-dependent project groups” [1]) up until the very last patch in the series [2], which redefines the integrated release in terms of those other relationships and a base set of projects. I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) I need to either get over that or decide what parts need tweaking for docs and support optimization. I'll get going on reviews -- thanks a bunch for all this compilation and for the good blog writing. Much appreciated. The relationships are also quite important for deployment units, because we're talking about what minimal set of things we're going to say work together. And we're going to be dictating the minimum lock step upgrade unit. Yes Integration in this sense (being part of that co-dependent group) is actually a burden both on projects and on developers. Want to upgrade Nova? Crap. I have to upgrade these other things too. Want to upgrade Swift? Sure, that's easy just upgrade that one thing. Any project that fully stands on it's own (like Swift or Ironic, given that keystone is optional) can be stood up on their own. Ok, they go in one bucket and you call tell people, you want this function, just install this project, it's a vertical on it's own. Heat works quite well against a compute stack you don't run yourself (teams doing this in HP all the time). I expect Zaqar to be like Swift, and be a thing you can just have. That's not the case for the compute stack, for better or worse. And, based on the User Surveys, the compute stack is what most people are trying to get out of OpenStack right now. So we should unconfuse that, create a smaller basic building block (that people can understand), and provide guidance on how you could expand your function with our vast array of great expansion sets. ++ OpenStack is enough parts that you can mix and match as much as you want, but much like the 600 config options in Nova, we really can't document every combination of things. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Fri, Oct 3, 2014 at 9:05 AM, Jay Pipes jaypi...@gmail.com wrote: On 10/03/2014 10:06 AM, Chris Dent wrote: On Fri, 3 Oct 2014, Anne Gentle wrote: I'm reading and reading and reading and my thoughts keep returning to, we're optimizing only for dev. :) Yes, +many. plus infinity. In my reading it seems like we are trying to optimize the process for developers which is exactly the opposite of what we want to be doing if we want to address the perceived quality problems that we see. We should be optimizing for the various user groups (which, I admit, have been identified pretty well in some of the blog posts). Precisely. This would, of course, mean enhancing the docs (and other cross project) process... Yep! This is something I harped on quite a bit in my second blog post. At the moment we're trying to create governance structures that incrementally improve the existing model for how development is being done. I think we should consider more radical changes, changes which allow us to work on what users want: an OpenStack that works. Yay! This ++ Also, I think what I've proposed does this. Because, as Sean already pointed out, our user surveys still say that most users are trying to get compute+identity+images+network when they try to get an OpenStack that works. Tightening the focus of the horizontally-scaling teams (qa, docs) to focus on that for a bit will help deliver a better experience to users. Expecting those horizontal teams to scale to accomodate every project under the big-tent umbrella is ludicrous, and I don't think anyone's expecting that to actually work out. I would much rather make it very clear to projects which are outside of what I keep wanting to call ring compute that they need to do their own docs, qa, etc - but they should be following the same workflow patterns and participating with the qa and doc teams working on ring compute. That collaboration makes them part of OpenStack, regardless of whether they co-gate with Nova or release on the same cadence as Nova. To do that I think we need to figure out two things: * how to fail faster * how to stop thinking of ourselves as being on particular projects More yay! I got hired to work on telemetry, but I've managed to do most of my work in QA related things because what's the point of making new stuff if you can't test it reliably? What I'd really like to say my job is is making OpenStack the best it possibly can be. If we keep focusing on the various services as entangled but separate and competing interests rather than on how to make OpenStack good, we're missing the point and the boat. That's not the point in my head, so let me clarify: I'm essentially saying this: Let's STOP co-gating the world, and only co-gate on non-optional functional dependency boundaries between projects, when those projects choose to co-gate with each other because the developers trust each other. By running a project's functional tests only against changes in that project, and encouraging (but leaving it up to the projects to decide whether they mutually run) two-service integration tests where there is an actual functional dependency between two projects, means each project actually has to unwrap its assumptions about the other project's behavior. We'll quickly learn where there are unstated assumptions about behavior as projects break other projects which they aren't co-gating with, and from that, we'll start shoring up those pain points for our users. Our job as developers is to make things easier (or at least possible) for the people who use the stuff we build. Naturally we want to make that as frictionless as possible, but not at the cost of the people's ease. There are many perverse incentives in OpenStack's culture which encourage people to hoard. For example it is useful to keep code in one's own team's repository because the BPs, reviews and bugs which reflect on that repository reflect on the value of the team. Who is that good for? So much of the talk is about trying to figure out how to make the gate more resilient. No! How about we listen to what the gate is telling us: Our code is full of race conditions, a memory pig, poorly defined contracts, and just downright tediously slow and heavy. And _fix that_. I think it's important to discuss both things: the gate structure (and various inefficiencies the gate *policies* create within the system) as well as the fragility and design of the code bases themselves. ++ What I think we need to do to improve is enhance the granularity at which someone can participate. Smaller repos, smaller teams, cleaner boundaries between things. Disconnected (and rolling) release cycles. Achieve fail fast by testing in (much) smaller lumps before code ever reaches the global CI. You know: make better tests locally that confirm good boundaries. Don't run integration tests until the unit, pep8 and in-tree functional tests have
[openstack-dev] [all][tc] governance changes for big tent model
As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On Thu, Oct 2, 2014 at 4:16 PM, Devananda van der Veen devananda@gmail.com wrote: On Thu, Oct 2, 2014 at 2:16 PM, Doug Hellmann d...@doughellmann.com wrote: As promised at this week’s TC meeting, I have applied the various blog posts and mailing list threads related to changing our governance model to a series of patches against the openstack/governance repository [1]. I have tried to include all of the inputs, as well as my own opinions, and look at how each proposal needs to be reflected in our current policies so we do not drop commitments we want to retain along with the processes we are shedding [2]. I am sure we need more discussion, so I have staged the changes as a series rather than one big patch. Please consider the patches together when commenting. There are many related changes, and some incremental steps won’t make sense without the changes that come after (hey, just like code!). Doug [1] https://review.openstack.org/#/q/status:open+project:openstack/governance+branch:master+topic:big-tent,n,z [2] https://etherpad.openstack.org/p/big-tent-notes I've summed up a lot of my current thinking on this etherpad as well (I should really blog, but hey ...) https://etherpad.openstack.org/p/in-pursuit-of-a-new-taxonomy After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png It turns out its really hard to figure out what the relationships are without digging deep into the code for each project, so I am sure I got a few things wrong (along with missing a lot of projects). -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][tc] governance changes for big tent model
On 10/02/2014 10:46 PM, Joe Gordon wrote: After seeing Jay's idea of making a yaml file modeling things and talking to devananda about this I went ahead and tried to graph the relationships out. repo: https://github.com/jogo/graphing-openstack preliminary YAML file: https://github.com/jogo/graphing-openstack/blob/master/openstack.yaml sample graph: http://i.imgur.com/LwlkE73.png To save people's time figuring out the colours: black: requires blue: can use red: depends on I'm not sure we need to explicitly track depends on. If a service has only one incoming requires or can use arrow, then it depends on whoever uses it, no? Also, once a service requires another one, it seems somewhat redundant to also say that it depends on it. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
