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 dholl...@netbsd.org