Those are all very reasonable suggestions, and I certainly won't argue against some regression tests for the checkpointing stuff.
Gabe On 03/04/11 17:17, Steve Reinhardt wrote: > On Fri, Mar 4, 2011 at 4:34 PM, Gabe Black <[email protected]> wrote: > >>> In general, we need to be much more cautious about updates that break >>> existing checkpoints. >> [...] Caution was not a factor. >> > Yea, that's my point ;-). > > >> As I said last time this came up, I'll won't take breaking checkpoints >> lightly, but my primary goal is improving the code as it is today, not >> compatibility. If I need to fix a bug or have a change that >> significantly enhances functionality, I'm going choose to do that over >> keeping old checkpoints working. I understand the changes can be >> painful, but it would be a mistake to trap ourselves like that. >> > I think you're misunderstanding me... I don't mean cautious as in "don't fix > bugs if you can't do it without breaking existing checkpoints". I'm > thinking of things like: > > - adding sensible defaults (when possible) to new unserialize statements, so > that (when possible) things work automatically instead of having > hypothetical post-facto email discussions about it ;-) > > - when necessary, adding warnings to commit messages that say "THIS WILL > BREAK EXISTING CHECKPOINTS" so people don't find out only after they've > incorporated a changeset that they have just committed themselves to a bunch > of extra work > > - working on that previously discussed python script that could automate > checkpoint updates when simple defaults are insufficient > > I think a big factor in making this happen would be having a regression test > that explicitly loads from a static checkpoint, so that in the process of > running regressions it would become obvious that you've broken that > capability. > > Steve > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
