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
