On 02/24/2015 03:21 PM, Joe Gordon wrote: > > > On Tue, Feb 24, 2015 at 6:57 AM, Daniel P. Berrange <berra...@redhat.com > <mailto:berra...@redhat.com>> wrote: > > On Tue, Feb 24, 2015 at 08:50:45AM -0500, Sean Dague wrote: > > On 02/24/2015 07:48 AM, Russell Bryant wrote: > > > On 02/24/2015 12:54 PM, Daniel P. Berrange wrote: > > >> On Tue, Feb 24, 2015 at 11:48:29AM +0000, Chris Dent wrote: > > >>> On Tue, 24 Feb 2015, Daniel P. Berrange wrote: > > >>> > > >>>> need to do more work. If this is so, then I don't think this > is a blocker, > > >>>> it is just a sign that the project needs to focus on > providing more resources > > >>>> to the teams impacted in that way. > > >>> > > >>> What are the mechanisms whereby the project provides more > resources > > >>> to teams? > > >> > > >> The technical committee and / or foundation board can highlight > the need > > >> for investment of resources in critical areas of the project, > to either > > >> the community members or vendors involved. As an example, this > was done > > >> successfully recently to increase involvement in maintaining > the EC2 > > >> API support. There are plenty of vendors involved in OpenStack > which > > >> have the ability to target resources, if they can learn where those > > >> resources are best spent. > > > > > > Indeed ... and if horizontal teams are the ones hit the most by the > > > extra work, each project should help with that burden. For example, > > > projects may need to take their responsibility for documentation > more > > > seriously and require documentation with features (content at > least, not > > > necessarily integration into the proper documentation deliverables) > > > instead of assuming it magically gets written later. > > > > Right, and I think this actually hits at the most important part > of the > > discussion. The question of: > > > > 1) what would we need to do to make different release cadences viable? > > 2) are those good things to do regardless of release cadence? > > > > The horizontal teams really can't function at different cadences. It > > completely breaks any flow and planning at turns them even further > into > > firefighting because now everyone has crunch time at different times, > > and the horizontal efforts are required to just play catch up. I know > > what that future looks like, the horizontal teams dry up because > no one > > wants that job. > > > > Ok, so that being said, what we'd need to do is have horizontal teams > > move to more of a self supporting model. So that the relevant content > > for a project (docs, full stack tests, requirements, etc) all live > > within that project itself, and aren't centrally synchronized. > > Installation of projects needs to be fully isolated from each other so > > that upgrading project A can be done independent of project B, as > their > > release cadences might all bit disparate. Basically, ever OpenStack > > project needs to reabsorb the cross project efforts they've > externalized. > > > > Then if project A decided to move off the coupled release, it's impact > > to the rest would be minimal. These are robust components that > stand on > > their own, and work well with robust other components. > > > > Which... is basically the point of the big tent / new project > governance > > model. Decompose OpenStack from a giant blob of goo into Robust > elements > > that are more loosely coupled (so independently robust, and robust in > > their interaction with others). Move the horizontal teams into > > infrastructure vs. content roles, have projects own more of this > content > > themselves. > > > > But it is a long hard process. Devstack external plugins was implement > > to support this kind of model, but having walked a bunch of different > > teams through this (at all skill levels) there ends up being a lot of > > work to get this right, and a lot of rethinking by teams that assumed > > their interaction with full stack testing is something they'd get to > > contribute once and have someone else maintain (instead of something > > they now need dedicated watchful eye on). > > > > The amount of full stack configurations immediately goes beyond > anywhere > > near testable, so it requires more robust project testing to ensure > > every exposed interface is more robust (i.e. the testing in pyramids > > from https://review.openstack.org/#/c/150653/). > > > > And, I think the answer to #2 is: yes, this just makes it all better. > > > > So, honestly, I'm massively supportive of the end game. I've been > > carving out the bits of this I can for the last six months. But I > think > > the way we get there is to actually get the refactoring of the > > horizontal efforts first. > > I pretty much fully agree that refactoring the horizontal efforts to > distribute responsbility across the individual projects is the way > forward. I don't think it needs to be a pre-requisite step for changing > the release cycle. We can do both in parallel if we put our minds to > it. > > My biggest fear is that we just keeping debating problems and > alternatives, > but continue to be too afraid of theoretical problems, to actually > take the > risk of effecting meaningful improvemnts in the operation of the > project. > > > I tend to agree with you on this. I don't think completing the > refactoring of the horizontal efforts is a pre-requisite of adjusting > the release model for projects that will be having a coordinated release > for the foreseeable future. That being said, maybe it would be easier > to pick off the projects that don't need to be part of a coordinated > release first.
Definitely. And doing so would produce a lot of lessons learned about what's needed to do this correctly. I expect that we can actually free a lot of projects to do that in Liberty cycle, get some feedback on how that's working, and evaluate what we can peel off in Marmite. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev