On Mon, Sep 28, 2015 at 11:29 AM, Ben Swartzlander <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
