> i think this a step in the wrong direction. i dont think it's good in the
> long run to support forked versions. forking is hard conceptually, and we
> should not pretend it's easy, developers should have a maximum incentive
> to merge code ...
Every feature that Linus didn't put in himself is a fork, if only for a
short time. Some things remain forked, in this weak sense, for much
longer, and some of them get widespread use. For instance, I believe all
of the 2.0 Redhat kernels (with the exception of 2.0.36?) were shipped
with patches. The large fd array patch may not make it into the 2.2 series
for a while, but it's likely that distribution vendors _will_ ship it so
it will be on a sizable portion of the installed base. Patches like the
crypto patches may never get merged into the official kernel, but I would
hope that most users eventually will be using them. Historically, it seems
most stable series kernels on big sites end up being run with patches. It
was certainly the case for post-1.2.13 and most of the 2.0 era.
The purpose here is not "support forks" - they're already a fact of life.
The idea is to support support, and make it easy to recognize when these
patches are in play. 2.2.0+foo saves the trouble of guessing, hey, are you
using patch foo? "Duh, I dunno, I didn't build it."
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/