[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: diff_memory.c compiler warning

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-08-19 21:01:35 CEST

Erik Huelsmann wrote:
> On 8/19/07, Blair Zajac <blair@orcaware.com> wrote:
>> Er, people can fix the commits they do :)
> That makes the build slaves fail longer than required (if they do). I
> hope we're all in this together, to get the best result, even though
> everybody has his own pet peeve...
> I also hope that people who make the commits can handle possible
> followup commits by others.
> Bye,
> Erik.
> PS: Note that the team thing isn't directed immediately and only at
> you, but more a remark in general that I think we don't have to wait
> for the original committer to fix the problem (or revert). If we want
> to be a team, I think everybody should accept that others may do that
> to their commits once in a while.

A couple of things. There's been a tendency in this project to have people fix
the commits they do. Did you offer to fix the ew fsfs unique transaction IDs
breaking the test suite on Windows :)

I got your point to fix simple things, but on the other side, not all the fixes
are simple. There may be deeper logic errors indicated by a simple warning then
just removing unused variables; the author may have intended something else.

For example, a simple document/code discrepancy that I found a month or so, Karl
stated it indicated a deeper issue in the code. So even there, to do a quick
fix on a comment would have covered up a deeper issue.

Finally, I also was working on getting another project into svn and didn't want
to get sidetracked, so better to send a note then get diverted.

We don't want to have people not comment or report compiler warnings if they are
expected to fix them instead of just dropping a note to the list.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 19 20:59:30 2007

This is an archived mail posted to the Subversion Dev mailing list.