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

[Scott Long]

M. Warner Losh wrote:
> In message: <20040618014912.O72823 at odysseus.silby.com>
>             Mike Silbersack <silby at silby.com> writes:
> : My opinion is based on the fact that software in contrib/ and in ports/ 
> : can change greatly from version to version, yet I'm getting attacked 
> : because I added a few lines of extra information to a utility.
> 
> Something else changed, therefore all change is fair game is not
> logical.  You are arguing to be right, rather than arguing for what's
> right for the project.  This little change isn't worth the push back
> you are giving to the folks that rightly point out that it changes
> things in -stable more than is traditional.
> 
> Warner

Stability in 4-STABLE has been pretty fast and loose over the years.
Most of this is because 5-STABLE has been so long in coming, so I
don't blame the changes that have happened.

HOWEVER....

I plan to start enforcing kernel and userland API and ABI stability
once 5-STABLE happens.  This _doesn't_ mean that the branch will be
locked down and that it's time for everyone to go off in a huff and
claim that they won't be able to fix bugs.  What it _does_ mean is
that changes that affect API/ABI stability and/or user experience
will need some form of justification.  That justification might
include POSIX compliance, security vulnerability, etc.  Adding to
the API via added library functions, new optional program flags, etc,
will pretty much be fair game.  The point is that there will be a
little more review and oversight going on so that 5-STABLE can
actually be advertised as being 'stable'.  Along with that, the
6-CURRENT cycle is going to be defined so that it doesn't take 5
years like the 5-CURRENT cycle.  These are things that will be
heavily discussed at the DevSummit, so I encourage those with an
opinion on this to participate in that.

Scott