<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 11:29 AM, Ben Swartzlander <span dir="ltr"><<a href="mailto:ben@swartzlander.org" target="_blank">ben@swartzlander.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've always thought it was a bit strange to require new drivers to merge by milestone 1. I think I understand the motivations of the policy. The main motivation was to free up reviewers to review "other things" and this policy guarantees that for 75% of the release reviewers don't have to review new drivers. The other motivation was to prevent vendors from turning up at the last minute with crappy drivers that needed a ton of work, by encouraging them to get started earlier, or forcing them to wait until the next cycle.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Yep, these were some of the ideas behind it but the first milestone did for sure create some consequences.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I believe that the deadline actually does more harm than good.<br></blockquote><div> </div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">In retrospect I'd agree with you on this. We ended up spending our major focus for the first milestone on nothing but drivers which I think looking back wasn't so good. But to be fair, we try things, see how they work, revisit and move on. Which is the plan last I checked (there's a proposal to talk about some of this at the summit in Tokyo).</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
First of all, to those that don't want to spend time on driver reviews, there are other solutions to that problem. Some people do want to review the drivers, and those who don't can simply ignore them and spend time on what they care about. I've heard people who spend time on driver reviews say that the milestone-1 deadline doesn't mean they spend less time reviewing drivers overall, it just all gets crammed into the beginning of each release. It should be obvious that setting a deadline doesn't actually affect the amount of reviewer effort, it just concentrates that effort.<br></blockquote><div> </div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">True statement, although there was an effort to have core reviewer 'sign up' and take ownership/responsibility specifically to review various drivers.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The argument about crappy code is also a lot weaker now that there are CI requirements which force vendors to spend much more time up front and clear a much higher quality bar before the driver is even considered for merging. Drivers that aren't ready for merge can always be deferred to a later release, but it seems weird to defer drivers that are high quality just because they're submitted during milestones 2 or 3.<br>
<br>
All the the above is just my opinion though, and you shouldn't care about my opinions, as I don't do much coding and reviewing in Cinder. There is a real reason I'm writing this email...<br>
<br>
In Manila we added some major new features during Liberty. All of the new features merged in the last week of L-3. It was a nightmare of merge conflicts and angry core reviewers, and many contributors worked through a holiday weekend to bring the release together. While asking myself how we can avoid such a situation in the future, it became clear to me that bigger features need to merge earlier -- the earlier the better.<br></blockquote><div> </div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">So this is most certainly an issue that we've been having in Cinder as well. It's a bad problem to have in my opinion and also I personally took a pretty hard stance against some new features, reworking of core code because it wasn't ready until the last week or so of the milestone and frankly they were HUGE changes.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
When I look at the release timeline, and ask myself when is the best time to merge new major features, and when is the best time to merge new drivers, it seems obvious that *features* need to happen early and drivers should come *later*. New major features require FAR more review time than new drivers, and they require testing, and even after they merge they cause merge conflicts that everyone else has to deal with. Better that that works happens in milestones 1 and 2 than right before feature freeze. New drivers can come in right before feature freeze as far as I'm concerned. Drivers don't cause merge conflicts, and drivers don't need huge amounts of testing (presumably the CI system ensure some level of quality).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">For the most part I think I completely agree with everything you've said above.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It also occurs to me that new features which require driver implementation (hello replication!) *really* should go in during the first milestone so that drivers have time to implement the feature during the same release.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">Yep, I most certainly should have pushed this in to the core code MUCH earlier. But to be honest, if you look at the life-cycle of the spec and the patch that implemented it; it was proposed very early, BUT there was very little useful input until after the mid-cycle'ish meetup in FTC. Was it a matter of review focus, bike-shedding, or me being lazy... maybe a little of all three.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I'm asking the Cinder core team to reconsider the milestone-1 deadline for drivers, and to change it to a deadline for new major features (in milestone-1 or milestone-2), and to allow drivers to merge whenever*. This is the same pitch I'll be making to the Manila core team. I've been considering this idea for a few weeks now but I wanted to wait until after PTL elections to suggest it here.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">The good news here I think is that we do have a number of proposals to revisit the various deadlines and how we set them. In my opinion putting a bit more process in place was good for the project, but I do think that maybe we swung a little too far in one direction. The reality though IMHO is still you live and learn and improve as you go. I think everyone on the Cinder team is pretty good at living up to that philosophy.</div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Ben Swartzlander<br>
<br>
<br>
* I don't actually care if/when there is a driver deadline, what I care about is that reviewers are free during M-1 to work on reviewing/testing of features. The easiest way to achieve that seems to be moving the driver deadline.<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>