RE: Kernel release numbering

[Massimo Cetra]

Jochen Striepe wrote: 
> On 03 Mar 2005, Massimo Cetra wrote:
> > So, why moving from 2.6.14 to 2.6.15 when, in 2/4 weeks, 
> i'll have a 
> > more stable 2.6.16 ?
> > Will users help testing an odd release to have a good even 
> release ? 
> > Or will they consider an even release as important as a -RC 
> release ?
> 
>  From my experience this won't work (at least it won't work 
> as inten- ded). I see a tendency of people going away from 
> Linux-2.6, going back to Linux-2.4, or even going to one of 
> the free BSD's. They go away because they have the feeling 
> they cannot rely any longer on the stabi- lity of the 2.6 
> kernel branch (there are other issues, but this one is common 
> with most people I talked).

I agree.

I have no problem testing new releases on my laptop.
I could't care less if it hangs or explode.

But when I have to upgrade a wide set of servers, 400 Km away from my desk,
I would be really happy if everything goes just fine.

This is the reason why I have 2.4 on my production systems and 2.6 on my
laptop.

Usable does not means that it simply works.
It means it works like as charm as the previous releases and has no
regressions.

> What you really need to avoid this (as far as I can see) is a 
> stable Kernel branch that does not give you a huge surprise 
> every time you do a kernel upgrade. Some mediocre statement 
> like "this one might be quite ok" is not enough -- you need 
> to declare that 2.6.EVEN is *stable*, that it is ready for 
> production use. When people give it a test, fix the bugs they 
> find, and release anew without adding any other 
> "improvements". This way the user gets the least surprises 
> when doing the next update -- and that is what gets you more 
> users on 2.6: the users will feel they can
> *rely* on the stable releases.
> 
> At least that's how it looks here. And yes, I *know* it's 
> harder to do development when you're stuck with maintaining a 
> stable branch. It's your choice.

The kernel renumbering would probably have some benefits over development,
but will _not_ enlarge the testing base.

That I think is that an enlargement of the testers is needed and it would
provide more regression reports.

As a mantainer of other products (not related to kernel and not as important
and big as the kernel), I have noticed that many people dowload patches but
only a few percentage reports error...

So... My proposal is simply this:
- TELL THE MEDIA (tv, radio, papers, websites) that users have to test to
help developing the kernel testing RC versions.

- write a clear monkey-proof howto on how to report regressions and bugs
 (many people does not even know how to do it)

- write some scripts to package a report and send it (almost) automatically
 (many people does not have time to gather informations)

- write a small script to  report working configurations (lspci,lsmod and
similar, kernel version & patches)
 (this would be used to have known working configurations)

It needs work, of course. It's not simple.

But the problem is avoiding bugs and regressions to have the stablest
kernel.
To avoid bugs, you have to know them.
To know them you need reports.
To have reports, you need a wide range of testers.
To let testers report problems, you need them to understand how to do it.

Tricking users with bogus stable releases is not a solution.

(obviously it is _NOT_ from a developer point of view.)

Massimo Cetra









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