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