Re: giant and hammer dates

[Mark Nelson <mark.nelson@inktank.com>]

On 07/30/2014 09:22 AM, Gregory Farnum wrote:
> On Tue, Jul 29, 2014 at 7:11 PM, Sage Weil <sweil@redhat.com> wrote:
>> We've talked a bit about moving to a ~4 month (instead of 3 month)
>> cadence.  I'm still inclined in this direction because it means fewer
>> stable releases that we will be maintaining and a longer and (hopefully)
>> more productive interval to do real work in between.
>>
>> The other key point is that we don't want a repeat of the firefly delay.
>> I think we should stay as close to a train model as we can.  If something
>> isn't ready by freeze, let it wait for the next cycle.  We shouldn't be
>> cramming things in at the end, especially big things.  As a general rule,
>> big things should be merged early in the cycle so that we have lots of
>> time to shake out the issues that only come out of lots of testing and
>> aren't obvious from code review.
>
> These two points are sort of opposing. In particular, extending the
> release cycle just makes the release seem more important, and
> increases the pressure to merge features in one cycle instead of
> waiting for the next one. (*Especially* if we continue to maintain
> every other named release.)
> I continue to prefer a 3-month cycle where we maintain enough merging
> discipline that the follow-on one-month shakeout period is something
> that the development team largely doesn't have to worry about, because
> the code is already working *before* we start it and we're just
> uncovering rare and longer-term bugs during that period.

Personally I'd prefer a longer testing and bugfix period for named 
releases.  4 months of development plus 2 months of testing. 
Development can easily go several weeks or a month over schedule 
(Personally I believe even good teams can't consistently stop this from 
happening, especially with something as complicated as next generation 
distributed storage!).  Our bugfix/test period gets too crunched as it 
is and our initial named releases feel more like release candidates. 
Soon after release we tend to make a bunch of point releases to fix 
semi-major bugs.  If we are doing that anyway, I think it would be 
better to just extend the test time and really make sure we've devoted a 
solid chunk of time for RC or Beta releases before the named release 
goes out.

I think the short point release cycle does help mitigate the merge 
pressure problem, but only if we are disciplined.  If the point releases 
are getting behind, stuff has to get cut.  6 months isn't that much 
longer to wait than 4 months, especially if people are already waiting 
until the 2nd or 3rd point release before they deploy for production 
(not sure if this is happening, but I suspect it is).

Mark

> -Greg
> Software Engineer #42 @ http://inktank.com | http://ceph.com
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>