On Wed, Jul 30, 2014 at 12:15 PM, Sage Weil <sweil@xxxxxxxxxx> wrote: > Basically, I think the trade-off is merge pressure vs backporting and > upgrade testing work... FWIW, over in Subversion (which is about as paranoid as Ceph regarding data corruption issues and compatibility), we have a 4-week "stabilization" period after a release candidate for a "minor" release (we have never issued a new major API release; so API compatibility is almost always kept). This stabilization period is when the tree switches over to enforcing prior review on all merges/backports in our STATUS file. This is documented at: http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization One particular point is that we will restart the soak (stabilization period) if something critical is found. (Alpha/betas are usually issued about 2 weeks prior to the first release candidate.) As a downstream user, I'd advocate the same for Ceph - while it's great to be on a strict release frequency train, I'd strongly prefer not to have a rehash of the firefly xfs corruption bug. I would also advocate that new features should not be backported to anything but the most recent "named" release - now that firefly is out, dumpling only gets critical bug fixes - no new features. Cheers. -- justin -- 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
