Re: RFD: Kernel release numbering

[Thomas Molina]

On Wed, 2 Mar 2005, Russell Miller wrote:

> On Wednesday 02 March 2005 19:37, Linus Torvalds wrote:
>
> > That's the whole point here, at least to me. I want to have people test
> > things out, but it doesn't matter how many -rc kernels I'd do, it just
> > won't happen. It's not a "real release".
> >
> > In contrast, making it a real release, and making it clear that it's a
> > release in its own right, might actually get people to use it.

> I agree with the first part of your mail that I quoted above.  Indeed, the -rc
> releases are not a "real release", and therefore people aren't going to test
> it.

> What you are missing is that if you use the method you have proposed. odd
> numberered kernels will stop being a "real release" as well to a great deal
> of users.

> The problem as stated is that people are not downloading and testing the test
> releases.

Define people. Some won't download a thing, they will take whatever the 
distros feed them. Some will download and test the latest patchset 
frequently, especially if someone asks. Some are interested only in a 
particular subsystem or feature.

> Your solution to that problem is to make test releases look like real releases
> and maybe people will test them anyway.

I believe the solution is slowly working its way out.  Previously there 
were only two stark choices, either you could be stable, safe, and boring, 
or you could use the development series and things could break horribly. I 
believe having a place where things could be tried out, such as the -mm 
kernels, was a great idea.

IMHO the 2.5 development series was long enough to be painful almost to 
the point of being counterproductive.  I think part of the problem with 
development series in general is/was a lack of focus. If the announced 
goal of the 2.5 series had been confined to changing module loading and 
latency/scheduling issues at the beginning, it would have been a lot 
shorter, and better.

I would like to see an even/odd stable/development cycle where the 
development cycle is limited to two or three major ideas and APIs don't 
change in stable cycles. New features not likely to cause breakage or new 
driver support could be targeted for the -mm kernels.
-
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/