Re: CVS commit: src

[David Holland <dholland-sourcechanges%netbsd.org@localhost>]

On Tue, Jan 18, 2011 at 11:42:29AM +0200, Antti Kantee wrote:
 > Speaking as a member of core, but voicing my personal opinion.
 > 
 > Please, roughly in the following order,
 > 
 > 1) stop proposing changes without impact
 > 
 >    every proposal should be about fixing a real problem.  removing
 >    operator cannot be justified by disk space waste or duplicate
 >    information going stale.  If there is envisioned impact -- i'm having
 >    trouble coming up with even a fictional case here -- it needs to be
 >    included in the proposal.
 > 
 > 2) stop making changes which do not fix problems
 > 
 >    every change can create a problem, so if a change does not work toward
 >    fixing a problem, the change itself is a problem.
 > 
 > 3) stop opposing changes without reason
 > 
 >    This is a live OS, there are changes.  if you want everything to stay
 >    like in NetBSD 1-4-U, use cvs export -D.  If you oppose a change, you
 >    need to present a case for a non-trivial problem created by the change.
 >    It is unnecessary to call on procedular problems when it is obvious
 >    that a discussion can never reach an agreement (cf. "1").
 > 
 > 
 > There are no winners here.

In general I agree but I have some quibbles:

(1) I would say more important here is to account for the full impact
of the change you're proposing. The problem with removing the extra
copy of operator is that it *does* have a substantial impact, a
negative impact, on people who are used to typing "more
/usr/share/misc/operator". The problem is not that removing the extra
copy serves no purpose; the problem is that the benefit is miniscule
and the cost is not.

Failure to take account of the social/user impact of proposed changes
is, I'd say, the primary cause of long bikeshed threads.

A change that *really* has no impact, like renaming local variables
for clarity inside compat_irix, doesn't need to be discussed; it can
just be made.

(2) I would also say that every change should have a *purpose*. Not
every valid purpose is solving a problem, except in a vacuous or
tautological sense.

More importantly though, if proposing something, it's important to
state and clearly articulate the purpose. Failure to explain what
you're trying to accomplish (and why that requires the change you're
proposing) results in lots of unhelpful suggestions.

(3) When a discussion reaches the state where agreement becomes
impossible is precisely the time it's most important to follow
procedure, IOW, take it to core.

Also, "this proposed change serves no purpose, not even code cleanup"
is a valid reason to oppose.

-- 
David A. Holland
dholland%netbsd.org@localhost