On 07/30/2014 09:22 AM, Gregory Farnum wrote:
On Tue, Jul 29, 2014 at 7:11 PM, Sage Weil <sweil@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
