[Mono-dev] revert of r104029/30/31
atsushi at ximian.com
Mon May 26 05:23:49 EDT 2008
Changing parameter names may result in bugs (especially when
there is a field that has the identical name). When it is mixed
with line ending changes, it becomes very hard to identify the
cause of the issue. Those changes should be done separately.
BTW I very much agree with Sebastien on that extra massive changes
could harm maintainers. I have been suffered from such changes
in sys.xml land many times.
Gert Driesen wrote:
> From: "Sebastien Pouliot" <sebastien at ximian.com>
> Sent: Monday, May 26, 2008 1:21 AM
> To: <gert.driesen at pandora.be>
> Cc: "mono-devel-list" <mono-devel-list at lists.ximian.com>
> Subject: [Mono-dev] revert of r104029/30/31
>> Please *post* your patches for review *before* committing them!
>> Those changes were obviously untested since they broke the unit tests.
> Sorry about that. I was too confident that these changes were harmless, my
> I'll look into this, and - if you want - post an updated patch for review.
>> They also mix formatting changes (not all in respect of mono style) with
>> code changes (parameter names) making this harder, than it has to be, to
> I'm pretty sure all the formatting changes respect the "mono style", but
> feel free to correct me.
> I know we had a "discussion" on whether braces for the class/namespace
> should go on a separate line or not, and I know you thought they should go
> on the same line. However, both the mono guidelines and several committers
> on #mono confirmed that they should go on a separate line.
> I don't think I want to spend an hour or two splitting up the argument name
> changes with the formatting changes, so if you prefer to keep the sources in
> the state they were before my changes then I'll just revert my local
> My formatting changes were limited to:
> * changes loads of spaces to tabs
> * removing loads of trailing tabs
> * moving braces on class/namespace declaration to separate line (probably
> less than 2% of my changes)
>> Also note that such *big* changes always cause a lot of conflicts for
>> the code maintainer(s), since they often have uncommitted code or patch
>> in testing. So a bit of warning before committing is a *minimum*.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list