On 09/28/2015 02:42 PM, Walter A. Boring IV wrote:
On 09/28/2015 10:29 AM, Ben Swartzlander 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.
But harm to whom? It certainly puts the pressure on driver
developers to make sure they get involved in the Cinder community and
get aware of when the deadlines are.
I believe it simply shifts the time in which drivers get into tree. My
$0.02 of opinion is, that if a new driver developer misses the
milestone, then they have the rest of the release to work on getting
CI up and running and ready to go for the next release. I'm not sure
I see the harm to the Cinder community or the project. It's a
deadline that a driver developer has to be aware of and compensate
for. We've had how many drivers land in the last 2 releases using
this requirement? I believe it's somewhere of 20+ drivers?
Walt I think you missed the point of my suggestion. I don't actually
care when drivers go in. What I care about is that features land early
so they can get appropriate review time and testing time, and so that
merge conflicts can be dealt with. It seems to me that many people
review nothing but drivers during milestone-1 so I suggest moving the
deadline so those reviews can happen later. The 3rd milestone is when
there should be no big architectural changes going on and is IMO the
safest time to merge drivers. So the harm of the milestone-1 deadline is
that is sucks all the oxygen out of the room, delaying features to
milestone-2.
-Ben
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.
I disagree here. CI doesn't prevent you from having a crappy driver.
Your driver just needs to pass CI tests. CI ensures that your driver
works, but doesn't ensure that it
really meats the core reviewers standards for code. Do we care? I
think we do. Having drivers talk directly to the db, or FC drivers
missing the FCZM decorators for auto zoning, etc.
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.
I'm not opposed to M-2 for new drivers, but I think it simply shifts
the headache of 3000+ line driver reviews to M-2 instead of M-1,
reviewers will spend their time reviewing core features and not look
at drivers until the M-2 deadline. Is that better or worse? I think
part of this is why we've raised the discussion of pulling drivers out
of Cinder tree.
I'm not clear how that helps the community and quality of drivers though.
Walt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
