On Thu, Jan 13, 2011 at 2:32 PM, Ryan King <r...@twitter.com> wrote: > # Fixed schedule > > We should set a fixed schedule and stick to it. Anything features not > ready at branch time won't make it and will be disabled in the stable > branch.
I like this idea, as long as we're willing to be flexible when warranted. Sometimes it is less work to finish a feature, than to rip it out. > # Trunk-first > > Everyone on chrome commits to trunk first. I suppose that's fine if it works for them, but it's not The One True Way. Changes that affect both stable and trunk branches should really be applied to stable first and merged forward. Here is a good presentation explaining why: http://video.google.com/videoplay?docid=-577744660535947210. Another reason is that committing fixes to a stable branch and then using "svn merge branch" from trunk means svn tracks everything that has been committed to branch and not yet to trunk, and merges it in. So it protects us somewhat against people committing a fix to trunk, then forgetting to commit to the stable branch. > I think the important > change we could make is to keep everyone closer to trunk. We spend a > good deal of effort back-porting patches between major versions. I > think we should make the major versions less different. This would > mean letting them live for shorter amounts of time and possibly making > them bugfix only. In theory I agree (see: policy for 0.4 and 0.5 stable releases). In practice, users overwhelmingly wanted more than that in between major releases. Not that users are always right, but this is an area where I think they are worth listening to. :) > I think if we made the major release schedule more predictable > people would be more comfortable with letting their new feature wait > until the next major version. In my experience it's not the unpredictability as much as "I'm feeling this pain Right Now and four months is too long to wait." > We should be more liberal about committing things to trunk early and > iterating on them there (rather than iterating on them in patches). I agree in the sense that we were too slow to branch 0.7 to have an open trunk to start work on. But I disagree in the sense that we shouldn't be committing works-in-progress to trunk because that becomes the baseline everyone else has to develop from. (I know at least one team with a nontrivial patchset against trunk from the 0.7 beta1 timeframe, back when it had the Clock struct that we committed prematurely.) IMO the right fix is to help the ASF make git an option; in the meantime the best workaround is a git-based workflow with git-jira-attacher and git-am as described in http://spyced.blogspot.com/2009/06/patch-oriented-development-made-sane.html and http://wiki.apache.org/cassandra/GitAndJIRA. > # Automate all tests > > I think the only way that we can keep people close to trunk and stay > stable is to build automated tests for *everything*. All code should > be exercised by thorough unit tests and distributed black-box tests. > Every regression should get a test. Agreed. > Chrome has a 6 week cycle. I think ours would be more like 4 months > for major releases. Four months feels about right to me, too, although for 0.7 + 1 I'd like to make it a bit shorter (beginning of April?) since we have several features (1072 being the most prominent) that just barely missed 0.7. > Whatever we do, I think the schedule needs to be more predictable, > which means that the contents of each release will be less predictable > (since its "whatever's ready at the appointed time"). Like the Chrome > presentation mentioned the idea isn't raw speed, but predictable > release schedules. I agree. At the least, I think it's worth trying. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
