On Tue, 15 Jun 2010 16:32:31 -0700, nathan binkert <[email protected]> wrote: >> I think the issue there is that our current regressions are not that >> thorough, and there was some hope that by delaying updates longer then >> users would get the opportunity to shake bugs out of the dev tree that >> the regressions didn't find. I don't know how successful that's been >> in practice though. >> >> IIRC, we had some plan for a while about freezing commits, etc. (e.g., >> we'd commit for 5 months then freeze for 1 month (excepting bug >> fixes), then update stable at the end of the freeze for a 6-month >> release schedule). Whatever happened to that? > I think what happened is that we just weren't disciplined (or > dedicated) enough to do it. The problem is that usage is so bursty, > I'm not sure that a 1 month freeze would actually do much. Perhaps we > should just update stable every 3 months and actually apply bug fixes > to it as people find them. Would named branches help?
I guess several things would help. More coverage in the regressions tests certainly will. Whatever happened to creating a new regression system? Having a release schedule and actually sticking with it would help. We could try a more community oriented approach with the 5 months - 1 month idea, and after 5 months we send an e-mail to M5 users, saying M5 10.10 (using ubuntu's numbering) is going to be moved into stable and please take 15 minutes to compile and run your benchmark on it and let us know any issues otherwise we might be breaking your code. Thoughts? Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
