Re: Changes in update-game-score.c

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 24 Jan 2014 00:42:35 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> > sumo changesets make maintenance harder
> 
> Sure, but the change that prompted this thread (trunk bzr 116113) 
> deleted 13 lines of code and added 8. That's a small changeset, not a 
> sumo one.

"Sumo" does not necessarily mean a lot of lines.  If there are several
unrelated issues taken care, it's a "sumo" change, for the purposes of
this discussion.  It means that reverting the commit gets rid of more
than just one issue.

> It's easy to find bug-fixing changes that behave the same way. For 
> example, the most recent bug-fixing patch that you installed (attached) 
> actually consists of multiple independent changes. One change replaces 
> fchmod with chmod on WINDOWSNT platforms, fixing a porting bug; but 
> another change replaces "!=" with "<" on WINDOWSNT, and this change does 
> not fix any bug.

No, you are mistaken: chmod is documented to be able to return both
negative and positive values, in addition to zero.  We care only about
the negative case.  By contrast, fchmod is documented to return only
zero or -1.  These two functions are different in this respect, so the
code cannot stay the same when one is replaced by the other.

Seen from another POV, I simply restored the previous code for
WINDOWSNT, i.e. the bug I fixed was that the code was changed in the
first place.

> This sort of thing happens all the time, and it's OK.

That it happens all the time doesn't yet make it OK.

> It'd be unreasonable to insist that every patch to Emacs now must
> fix just one bug and must not make any changes that do not fix the
> bug.

The only unrelated changes that can be done are whitespace changes,
comment changes, formatting changes, and other similar stuff.  It
might be hard to reach that ideal, but we should strive.