Open Stack

I can definitely see your logic, but we've a history in cinder of vendors
trying to cram drivers in at the last minute which we very much wanted to
stop dead. I might suggest that the second milestone, rather than the first
might be a better one to dedicate to driver reviews...

An interesting thing is that, from the point of view of cinder core, we
don't need more drivers. We've drivers coming out of our ears. Sure it is
incrementally better to get more drivers, but we've got far more to gain
from harnessing the developers of companies who want to merge new drivers
for core work (or ci improvements, or translation or docs improvements or
whatever) than we do from yet another driver. Increasing the bar for enter
slightly does us no major harm that I can tell - there's a clear benefit
from having your driver in tree, so if there's a small 'tax' to get added
then I suspect we can benefit from it substantially.

Definitely worth reviewing deadlines and other bureaucracy occasionally and
working out if it is still serving us well.

Cheers
On 28 Sep 2015 20:32, "Ben Swartzlander" <ben at swartzlander.org> wrote:

> 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.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150928/cdbda197/attachment.html>