I sympathize with Ali's concerns... the current situation is pretty much the opposite extreme of the 3-6 month release cycle I was advocating not that long ago. My main motivation was that a longer cycle would allow more time for people to find problems, and the criticism was that a lot of the problems were being found by people who would be pulling from m5-stable anyway, so the latency didn't help. But now we're at the other end of the spectrum, where even the people who pull from the dev repo aren't getting a chance to try it.
The auto-update after regression strategy is nice in theory, but as long as our regressions are as feeble as they currently are then Ali's got a point. And I'm not talking about just the number of tests, but also running the tests on a variety of platforms (linux, OS X, 32-bit, 64-bit, etc.) and with a variety of versions of gcc, scons, swig, python, etc. I don't have a great solution other than beefing up the regressions... imposing a minimum age would be awkward, as that implies that we'd run the regressions on a snapshot that's a week old since that would be the "release candidate", but of course you want to be testing the head of the tree as well. There's also the question of how you'd get urgent patches into m5-stable if there's a significant latency yet we want m5-stable to simply track the dev repo. (I guess we have that problem already, but increasing the latency would just make it worse.) Thinking about that gets you back to the idea of keeping the dev repo as a patch queue on top of m5-stable, but we already rejected that as too ugly (and probably rightly so). I think the bottom line is that as long as you want to do extensive non-automated testing before declaring something as "stable" then you have to have (1) some sort of freeze prior to that point so that your testers are all testing the same thing (modulo bug fixes) and (2) some group of people who are going to be doing that testing, i.e., neither waiting for "stable" nor trying to stay on the bleeding edge by bypassing the freeze. Maybe it's not realistic to expect that here. Maybe the only practical approach to improving the situation is to beef up the regressions. Other than the OS X bits, we could probably get a lot of mileage out of setting up a bunch of VMs on zizzer. We should also be more proactive about creating new regressions whenever someone turns up a bug that the current regressions didn't catch. I could be wrong though... Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
