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