Hi Sage, From my (biased) point of view, the upside is that it will give me more time to complete the locally repairable code for Giant ;-). The downside is that it puts a little less pressure to improve the tools and methods that make a rapid release cycles possible (i.e. unit tests, bug tracking, patch acceptance workflow, package building/gitbuilder, teuthology, pulpito, upgrades testing, ...). In a perfect world Ceph could sustain a three month release cycle without inconveniencing anyone. A longer release cycle (five or six months) would encourage even more complex / bigger changes within a release cycle. It would also probably encourage Ceph developers to forget about the release process tools during two or three months and not improve them as they should be. IMHO the test cycle is significantly slowing down the release process and a faster, more comprehensive test cycle would help a lot. Each commit should be unit / functional tested within seconds, locally (see https://github.com/ceph/ceph/blob/master/src/test/osd/types.cc#L1295 for instance). It is usually more difficult to diagnose / fix a border case when it is discovered during integration tests (i.e. teuthology) rather than with a unit / functional test designed for it. Creating unit tests is often problematic because some of the code base cannot be easily isolated. With a continuous effort to re-arrange parts of the code to be more test friendly, this can eventually be resolved. Every commit proposed to master should be run against the relevant teuthology suite to help the reviewer. The problem here is that it requires more resources than what Ceph currently has. Harvesting more machines, making it possible for people and organizations amicable to Ceph to easily donate virtual machines could probably help. This deserves a separate discussions but I wanted to expand on what I meant by "test cycle" and its impact on the release cycle. Cheers On 30/07/2014 05:11, Sage Weil 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. > > Anyway, how about: > > Freeze Approx Release > Giant Mon Sep 1 Mon Sep 29 > Hammer Mon Jan 4 Mon Feb 2 > > That gives us another month for Giant, then September to shake out > anything issues. And then three full months before the Hammer freeze. > > What say ye? > sage > -- > 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 > -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
