On Tue, Sep 4, 2012 at 5:31 PM, Mark A. Hershberger <mah(a)everybody.org> wrote:
Or maybe these simply the differences in the sorts of
people like to do? Or maybe its a bit of both?
I think you're right that stylistic differences are at play.
One possible bit of guidance we can give is "make things as simple as
possible, but no simpler". That is, having a large change broken up
into smaller bits can sometime mean creating a jigsaw puzzle for the
reviewer to piece together prior to reviewing your big change.
Nonetheless, I know that, for example, some reviewers prefer to see
things broken up, and others don't. An example might be a big change
that requires a new API. Some reviewers don't mind reviewing that API
in isolation, whereas other reviewers want to see the calling code.
If the API is an obvious and welcome change that can stand on its own,
then that's going to be the better strategy. However, if the calling
code could have been done differently (and much better) with a
different API, then refactoring might be made harder by the fact that
there are now people depending on the previously reviewed/committed
I think most reviewers agree that several unrelated changes bundled up
into the Omnibus MediaWiki Cleanup and Terrorism Prevention Commit of
2012 is a bad thing. And no, those reviewers are not in league with