On Thu, 2011-01-13 at 14:32 -0800, Ryan King 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.
In general, I agree, if we want a cadence, we're going to have to exert some pressure to release at an agreed upon time. But, as Jonathan says, we need to be flexible. Even on this project, there have been times when we've put a clock on a stable release, and had problems with people rushing in poorly tested changes. > # Trunk-first > > Everyone on chrome commits to trunk first. 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. Currently we add new features in stable branches, > but 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. I'll call your keep-close-to-trunk, and raise you a: * branch as soon as all planned features land in trunk * iteratively release betas w/ bug-fixes only * release candidates are actual candidates for the final (not releases) The time between creating the branch and making the release should be as short as practical, and there should be no backward incompatible changes between the first beta, and final release. > We should be more liberal about committing things to trunk early and > iterating on them there (rather than iterating on them in patches). If > the features are unstable we can either hide them behind configuration > flags or remove them when we cut a stable branch. As Jonathan said elsewhere in this thread, Git is finally within reach, and would solve many of the current technical limitations with our current process. I'd favor that as a first-step. > # 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. Absolutely. > Chrome has a 6 week cycle. I think ours would be more like 4 months > for major releases. > > 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. Yeah. Sounds good. -- Eric Evans eev...@rackspace.com
