I don't really desire a single changeset. The most important thing (to me, anyway) is that changesets transform the code from one working state to another working state. So if there are changes to the SConstruct/SConscripts that are *necessary* for the changes in the ISA parser to work, then they should be in the same changeset, so that applying one patch but not the other doesn't break things.

Given that, it's desirable (though less imperative) to break things down into small self-consistent units.  There's no requirement that a patch "stand alone" in terms of completely providing a tangible feature or fixing a bug; it only needs to "stand alone" in terms of not breaking things.

It's also very valuable to describe the purpose and motivation of changes. For example, your description of why it's valuable to switch from relative to absolute paths was very enlightening, but wasn't anywhere in the patch or the commit message, where it would be very useful to have for posterity.  In general, we tend to put too much in the commit message and not enough in comments, but in this case (since the history will be irrelevant to people who are reading the code) I think the commit message is where that should go.

So in this case, I think it would be very appropriate to have a patch that's something like "Switch SConscripts from relative to absolute pathnames", then in the commit message you could explain why it's functionally neutral by itself, but is important preparation for the upcoming ISA splitting changes.

This is really the same concept as committing all the code to enable splitting ISA outputs in one patch, and then committing the changes to the ARM ISA description in a second patch (which is the right thing to do)---note that the first patch by itself doesn't really "do anything" either, but since it doesn't break anything, separating the ARM changes gives us smaller but still self-consistent changes.

Obviously this is all somewhat subjective; if anyone else wants to add anything to the discussion please speak up.  Perhaps if we come up with agreed-upon guidelines it should go on the wiki.  There's a little bit of a discussion in one of the bullets at http://gem5.org/Commit_Access but it could be expanded.

I do think that we have quite a bit of ambiguity around what is and isn't an acceptable change set. I agree with Steve's comment that each change set shouldn't break the repository in some way, it might not do anything visible, but it should still compile (purely from the point of view of someone who has gone back to try and figure out when something broke it's pretty annoying if the code doesn't even compile). That is certainly one side of the acceptable change set, but the question then remains what is the opposite side? While others in the past seem to be annoyed that fixing white space was in the middle of some other change I don't really care -- if i don't fix it now it's probably never going to get fixed anyway. Similarly, it's less work on everyone involved if 12 random one-line bug fixes are committed as one change set rather than 12. Thoughts?

It's tough to make firm rules about when a changeset is "too big"... it is often subjective. I agree that we don't want to be too pedantic about mixing whitespace changes and bug fixes, or going for the absolutely minimal self-sufficient change.  On the other side of the argument, though, is my recent encounter with an enormous changeset of Nate's described as "Major changes to how SimObjects are created and initialized".  One side effect of that massive changeset, unmentioned in the commit message, is that the python-generated enums went from being embedded in structs to being in a common namespace, and Nate doesn't remember all the reasoning that went into that change.  I'm not blaming Nate specifically, but that's definitely a case where it would have been really valuable to make that enum change as a separate changeset, both so it could be clearer what the scope of the impact was (e.g., it would be nice to experimentally try rolling it back, but I have no idea how far-reaching that would be) and so that it would have actually been documented in its own commit message.

The situation immediately above here is another example where a small but notable change (in terms of the relative vs. absolute path names) went undocumented because it was buried inside a much larger change.

As an aside, I will mention that I'm strongly opposed to measuring complexity purely in terms of number of lines changed.  I've seen cases in the past where people have wanted to break up changesets just because they were unwieldy in size... while that's a good motivation to see if a changeset can be split into funcitonally independent pieces, it's not a justification for splitting it into two parts that don't stand alone functionally.