Open Stack

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.

I believe that the deadline actually does more harm than good.

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.

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.

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...

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.

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).

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.

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.

-Ben Swartzlander


* 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.