+1 I'm also concerned with our lack of regression testing. A lot of this is done by individual committers firing up EC2 clusters and running basic sanity checks and workloads. Most of the bugs we are finding pop up under heavy load.
It would be great if the community could identify and contribute use cases that could be bundled into a regression test suite. On Fri, Feb 11, 2011 at 11:35 AM, Gary Dusbabek <gdusba...@gmail.com> wrote: > I've been uncomfortable with the amount of features I perceive are > going into our maintenance releases for a while now. I thought it > would stop after we committed ourselves to having a more predictable > major release schedule. But getting 0.7.1 out feels like it's taken a > lot more effort than it should have. I wonder if part of the problem > is that we've been committing destabilizing features into it? IMO, > maintenance releases (0.7.1, 0.7.2, etc.) should only contain bug > fixes and *carefully* vetted features. > > I've scanned down the list of 0.7.1 changes in CHANGES.txt and about > half of them are features that I think could have stayed in trunk. I > think we did this a lot with the early maintenance releases of 0.6 as > well, probably in an effort to get features out *now* instead of > waiting for an 0.7 that was not happening soon enough. We've decided > to pick up the pace of our major release schedule (sticking to four > months). I think maintaining this pace will be difficult if we > continue to commit as many features into the minor releases as we have > been. > > I'm willing to concede that I may have an abnormally conservative > opinion about this. But I wanted to voice my concern in hopes we can > improve the quality and delivery of our maintenance releases. > > Gary. >
