Re: RFD: Kernel release numbering

[Steven Rostedt]

On Thu, 2005-03-03 at 13:38 -0800, Stephen Hemminger wrote:
> In all this discussion, I see a couple of underlying problems. The first
> is what is the definition of stability.  To many (mostly kernel developers)
> the definition of stability "S" depends on number of bug reports "B":
> 
> 	S(infinite) = B(0)
> 	S(X) > S(Y) iff B(X) < B(Y)
> 
> The problem is that the kernel community never sees many problems (filtered
> through distro's), and the severity and importance of problem reports
> is confused. Bug tracking could help, but it would have to be universal
> and painless; bugzilla doesn't cut it.
> 
> But many end-user's and IT types seem to feel that the definition 
> of stability is based on rate of change, ie patches (P) over time.
> 	
> 	S(X) > S(Y) iff P(X)/t > P(Y)/t
> 
> These are the people who can't believe 2.6 is stable because they see so
> much change. Having 2.6.x.y may make this group happy, but probably only
> after such a long period that the the mainline kernel is 6 months ahead.
> 

As I see it, there's those that would join in at different times. If the
point was to get as many people moving to newer kernels, then this would
make the most people comfortable to try a newer kernel. Maybe not the
latest and greatest, but at least one that is closer to the newest one.

Some might join 6 months behind, others 1 month and even those at 1
week. I've talked to different people, and there are many at the 1 week
point (the ones with the most critical systems would be at the 6 month,
but the 1 weekers are the ones that would put it on a more non essential
machine). 

> The whole point of the continuous 2.6 process, 
> was to avoid having the 
> multiple tree backporting mess that 2.5/2.4 had, especially the distro kernels
> were all some hodge-podge of 2.5 and 2.4 stuff. Fixing the same bug on multiple
> branches is a fundamentally flawed process that is sure to allow some bug fixes
> to be missed.
> 

Truth be told... don't worry about backporting fixes. This is the Open
Source world, many eyes, and many developers.  When a bug is reported,
say to 2.6.x.y, then let some new kernel developer try to fix it, or
whoever. Maybe even the one who reported the problem can fix it. But for
that branch only. If this bug is in a earlier branch, then don't worry
about it until someone else hits it, or say the one who fixed it, then
goes back and checks other branches only if they want to. 

I'm saying, just have the branches available, with no guarantee that
they have all the backported bugs, since no one is going to do it. But
if someone wants it, then they can have a go at it. Maybe even a distro
might add to it.  This might just give people a central repository to
all the fixes applied to a specific branch.  Again, only bug fixes and
nothing more.

> The third group are those that install release 2.6.X and have some problem;
> nobody wants to believe their problem is unique. So often, the user says makes
> the fallacious argument that "if I had a problem, then all users will have the
> problem, therefore it is unstable." These people will never be happy, they can
> stay on 2.2.

If there problem is truly a problem and if these people are capable of
fixing it themselves or finding someone else to fix it. Then again, you
have the fix at some point available for all.

-- Steve


-
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/