Open Stack

On Mon, Sep 28, 2015 at 11:29 AM, 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.
>

​Yep, these were some of the ideas behind it but the first milestone did
for sure create some consequences.​


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

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


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

​True statement, although there was an effort to have core reviewer 'sign
up' and take ownership/responsibility specifically to review various
drivers.​


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

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


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

​For the most part I think I completely agree with everything you've said
above.​


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

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


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

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


>
> -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/42ec47f7/attachment.html>