Open Stack

On Mon, Sep 28, 2015 at 12:11 PM, Duncan Thomas <duncan.thomas at gmail.com>
wrote:

> 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...
>
​I guess we're not waiting until the summit :)  So honestly I think the
whole driver freeze thing should just be a part of the regular
feature-freeze rules and requirements.  If the code gets submitted late;
well the submitter runs the risk of it not getting reviewed and not making
it.  That's life, and no amount of PM's on IRC or email pleading for a
review really sway me in those cases.

We've given this weird expectation to folks that "if you submit X by date
Y, we guarantee it'll merge" which is not only inaccurate, but completely
unfair.  It needs to be clear that there is a 6 month (actually more like 4
or 5) cycle to get your code in.  The longer you wait, the less likely
everything will get reviewed and merged.​  Sorry, but that's how it goes; I
personally stopped treating drivers as 'special' submissions a while ago
and have no intention of going back to pretending they're something
"special".  They're just another feature add IMHO.


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

​True that!!!  What are we at like, 80 or something now?​

​  Anybody interested in this topic come chat with me at the summit
(shameless plug for Griffith's agendas on removing drivers from
cinder/volume/drivers..., or at least coming up with a different method of
implementing them)  :)

It's a hard problem, no easy answer.  I also argue that "good" drivers do
make Cinder better; but we shouldn't make calls on what's good and bad
other than code review.

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
>>
>
> __________________________________________________________________________
> 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/6f9865a1/attachment.html>