cvs commit: src/sys/sys mbuf.h src/sys/kern uipc_mbuf.c uipc_syscalls.c src/usr.bin/netstat mbuf.c src/lib/libc/sys sendfile.2

[M. Warner Losh]

In message: <20040618085237.GA19561 at samodelkin.net>
            Max Khon <fjoe at samodelkin.net> writes:
: Hi, Ken!
: 
: On Thu, Jun 17, 2004 at 05:48:27PM -0400, Ken Smith wrote:
: 
: > I may work with student programmers too much, but I'm afraid my imagination
: > is a bit better than yours in this case.  :-(
: > 
: > I don't defend it as being the right way to do things, but in cases where
: > the user is interested in "most of" the output of something they will often
: > take the approach of removing things they don't want instead of selecting
: > things they do want.  This change would add an extra line to what the
: > next stage of processing would see if that approach is used.
: > 
: > This particular change is a case of nit-picking.  It's small, hard to
: > imagine how it could effect someone, etc.  But even Bosko said more
: > caution 'next time' would be good, I'm just emphasizing why.  To some
: > extent the output of programs has been an API ever since pipes were
: > invented.  And unless I'm severely mistaken one of the things we have
: > tried to avoid is changing API's once a branch goes -STABLE.
: 
: Yes, this is a case of nit-picking.
: 
: And I think it might be better if people will stop mentoring
: other developers when they are not asked to (this is not directed to you).

But Ken has been asked to.  HE's on the re@ team, and they monitor the
-stable branch.

Also, there are many times that it is *GOOD* to mentor other
developers.  They sometimes go off the rails and need some help to get
back on the rails.

Personally, I think people in this discussion are too worried about
being RIGHT and less worried about doing what's RIGHT for the
project.  That's the real issue.

Warner