Re: [openstack-dev] [all][tc] governance changes for big tent model

2014-10-03 Thread Eoghan Glynn

 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

2014-10-03 Thread Thierry Carrez
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

2014-10-03 Thread Doug Hellmann

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

2014-10-03 Thread Doug Hellmann

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

2014-10-03 Thread Doug Hellmann

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

2014-10-03 Thread Anne Gentle
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

2014-10-03 Thread Sean Dague
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

2014-10-03 Thread Chris Dent

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

2014-10-03 Thread Chris Dent

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

2014-10-03 Thread Doug Hellmann

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

2014-10-03 Thread Dean Troyer
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

2014-10-03 Thread Jay Pipes

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

2014-10-03 Thread Joe Gordon
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

2014-10-03 Thread Eoghan Glynn


- 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

2014-10-03 Thread Joe Gordon
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

2014-10-03 Thread Doug Hellmann

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

2014-10-03 Thread Devananda van der Veen
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

2014-10-03 Thread Devananda van der Veen
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

2014-10-03 Thread Devananda van der Veen
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 

Re: [openstack-dev] [all][tc] governance changes for big tent model

2014-10-02 Thread Devananda van der Veen
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

2014-10-02 Thread Joe Gordon
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

2014-10-02 Thread Chris Friesen

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