On Thu, Jan 13, 2011 at 4:04 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > 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.
Two things: First, I think a key part of how you make this successful (both for Chome and for continuously deployed software like large services) is that non-trivial changes almost always have to be hidden behind flags until they're ready for wide use. Second, I think this will only work well if we are somewhat strict about it. >> # 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 guess I don't care as much about the mechanics of this as the intent– which is to keep stable and trunk closer together. And to keep people working on a more common base. >> 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. :) Perhaps minor things are worth adding in a stable branch. I think this is an area where judgement can come into play. >> 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." Perhaps waiting is the biggest pain for users, but for developers unpredictability is just as big a problem. If I don't know when release N+1 is going to happen I might try to hurry to get my feature into release N. If I have confidence that release N+1 will come promptly at a scheduled time I can set my expectation appropriately. >> 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.) So we made a mistake once. :) I think committing large changes in smaller pieces will be a net positive, even if it occasionally trips us up. For example, I think work on counters between our team and Sylvain has improved dramatically once we committed 1072. > 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. So you're proposing that we use git to keep long-running feature branches? >> # 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. Like I said, we're going to have to figure out the right pace, but we should try and stick to it. >> 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. Good. -ryan
