Re: starting with 2.7

[Theodore Ts'o]

On Mon, Jan 03, 2005 at 12:18:36PM -0500, Bill Davidsen wrote:
> I have to say that with a few minor exceptions the introduction of new
> features hasn't created long term (more than a few days) of problems. And
> we have had that in previous stable versions as well. New features
> themselves may not be totally stable, but in most cases they don't break
> existing features, or are fixed in bk1 or bk2. What worries me is removing
> features deliberately, and I won't beat that dead horse again, I've said
> my piece.

Indeed.  Part of the problem is that we don't get that much testing
with the rc* releases, so there are a lot of problems that don't get
noticed until after 2.6.x ships.  This has been true for both 2.6.9
and 2.6.10.  My personal practice is to never run with 2.6.x release,
but wait for 2.6.x plus one or 2 days (i.e. bk1 or bk2).  The problems
with this approach are that (1) out-of-tree patches against official
versions of the kernel (i.e., things like the mppc/mppe patch) don't
necessarly apply cleanly, and (2) other more destablizing patches get
folded in right after 2.6.x ships, so there is a chance bk1 or bk2 may
not be stable.

We could delay the destablizing changes until after rc1 ships, and
ship rc1 about 2-3 days after 2.6.x is released, so that the really
obvious/critical regressions can be addressed immediately.  The
problem with this approach though is that some people will just wait
until rc1 ships before they start using a new kernel version, and we
lose the testing we need to stablize the release.  

The real key, as always, is getting users to download and test a
release.  So another approach might be to shorten the time between
2.6.x and 2.6.x+1 releases, so as to recreate more testing points,
without training people to wait for -bk1, -bk2, -rc1, etc. before
trying out the kernel code.  This is the model that we used with the
2.3.x series, where the time between releases was often quite short.
That worked fairly well, but we stopped doing it when the introduction
of BitKeeper eliminated the developer synch-up problem.  But perhaps
we've gone too far between 2.6.x releases, and should shorten the time
in order to force more testing.  

							- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/