[Mono-dev] [Fwd: [Mono-patches] r106626 - in trunk/mcs/class/System.Configuration: . System.Configuration Test/System.Configuration Test/standalone]
jb at nurv.fr
Thu Jun 26 11:59:36 EDT 2008
On 6/26/08, Gert Driesen <gert.driesen at telenet.be> wrote:
> Sorry dude, but this wasn't a large changeset.
Alright, so because you simply *refuse* to hear what we telling you,
let me rephrase and explain.
> If the definition of a large changeset is a patch which adds a large set of
> unit tests, then I'm guilty as charged.
> Apart from removing a few extra tabs (my mistake), everything I changed is
> documented in the changelog and covered by unit tests or standalone tests.
It's not because changes are covered by unit tests and described in
the ChangeLog that changes are *atomic*.
We're programming right, so we believe in the separation of concerns?
I (at least try) to apply the separation of concerns in commits as
well. I like to think to a SCM as an important developer tool, and I'm
not the only one to monitor patches coming in. By having small self
contained patch, it's much easier to navigate through history, detect
defects, and revert them precisely. Am sorry that you don't see the
issue, but there's one. Really.
And not only that allow us to be aware of the code coming in, and to
work on it if needed, but it also allow us to review the code, we,
maintainers, that are asked to maintain a piece of code. By checking
patches in the way you're doing it, you're simply preventing us to do
this work efficiently. And as I said, it's not because you're adding
tests and writing ChangeLog entries that some mistakes are not buried
into the hundred of lines of changes. We already saw that happen
To sum up, you're checking in large set of tests + behavior changes +
style changes all in the same commit. And that's not a good practice,
> Please be reasonable. What more can you ask?
Please listen when different people like Atsushi or Sébastien (or even
me for that matters) repeatedly say the same thing.
And I'd ask you to follow their advices.
Jb Evain <jb at nurv.fr>
More information about the Mono-devel-list