linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <willy@w.ods.org>
To: Jan Rychter <jan@rychter.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4 future
Date: Wed, 3 Dec 2003 22:14:49 +0100	[thread overview]
Message-ID: <20031203211449.GB11325@alpha.home.local> (raw)
In-Reply-To: <m2k75dzj6n.fsf@tnuctip.rychter.com>

Hi,

On Wed, Dec 03, 2003 at 01:26:56PM -0800, Jan Rychter wrote:
> I am terrified of the following scenario, which is extremely probable to
> happen soon:
> 
>   1) 2.4 is being moved into "pure maintenance" mode and people are
>      being encouraged to move to 2.6.
>   2) While people slowly start using 2.6, Linus starts 2.7 and all
>      kernel developers move on to the really cool and fashionable things
>      [3].
>   3) 2.6 bug reports receive little attention, as it's much cooler to
>      work on new features than fix bugs. Bugs are not fashionable.
>   4) In the meantime, third-party vendors are confused and do not
>      support any kernel properly [4].

This was already already discussed when 2.4 was about to born. But finally
people didn't not jump that fast to 2.5 in part because early releases were
not stable enough for all developpers.

> What are my suggestions? Two main points, I guess:
> 
>   1) Please don't stop working (and that does include pulling in new
>      stuff) on 2.4, as many people still have to use it.
> 
>   2) Please don't start developing 2.7 too soon. Go for at least 6
>      months of bug-fixing. During that time, patches with new features
>      will accumulate anyway, so it isn't lost time. But it will at least
>      prevent people from saying "well, I use 2.7.45 and it works for
>      me".

I think the exact opposite. I too have been hit by recurrent API changes in
2.4. For instance, I remember I once wanted to upgrade to the latest tg3
driver because of a problem in production, but this required me to include
NAPI support in the kernel. Not that pleasant on a stable release.

I think that what incitates people to constantly break APIs and backwards
compatibility is the adding of new features in stable kernels, which is
induced by an overly long release cycle. When developpers have fresh ideas
in their head, they need to implement them right now. If you tell them "wait
6 more months before playing with the dev kernel", what happens ? They test
it on the stable one, and once it works, they propose the patch, people like
you and me find it cool, download it, pressure Marcelo to include it because
we're lazy (don't want to do the job twice), then something breaks.

The other solution: start the new devel kernel even before the stable release
so that developpers can start to play again and not only do the dirty boring
job of running after bug reports. A good developper will always try to fix a
problem in a stable kernel before playing with any other nice feature. But he
needs motivation and not frustration. So I'm totally for a permanent
development tree and regular stable releases with only bug fixes. It's about
what we have with 2.4 at the end of its life. One release every 6 months with
intermediate development releases. But in this case, it's the second digit
and not the third which should be incremented every 6 months.

> [5] Please don't tell me to buy an open-source supported 3D card. I've
>     seen such answers before and they are ridiculous. There is no such
>     card on the market if you want anything like reasonable performance.

Open a paypal account to fund development of these drivers under NDA if you
need... How can you require people you don't even know to find specifications
of closed chips on their own time to write a kernel driver for you ? If it
was that simple, I would ask that someone ports Linux to my under-used G400
so that this graphics card with lots of RAM (32 MB) could embed one more
penguin in my system !

Willy


  parent reply	other threads:[~2003-12-03 21:18 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-01 14:25 Linux 2.4 future Marcelo Tosatti
2003-12-01 15:04 ` Ian Kent
2003-12-01 15:33   ` Christoph Hellwig
2003-12-01 21:36     ` Peter C. Norton
2003-12-01 23:54       ` Arjan van de Ven
2003-12-02  1:11         ` Ian Kent
2003-12-02 20:13           ` Peter C. Norton
2003-12-02 20:10         ` Peter C. Norton
2003-12-02 20:18           ` Arjan van de Ven
2003-12-02 20:46             ` Peter C. Norton
2003-12-03  1:23               ` Ian Kent
2003-12-03 10:36                 ` Matthias Andree
2003-12-03 14:49                   ` Ian Kent
2003-12-03 15:00                     ` Matthias Andree
2003-12-04  6:24                       ` Ian Kent
2003-12-02 21:56             ` Bryan Whitehead
2003-12-02  8:17       ` Christoph Hellwig
2003-12-02  1:09     ` Ian Kent
2003-12-02  2:23     ` snpe
2003-12-02  6:39       ` Jan-Benedict Glaw
2003-12-02 18:04         ` Linus Torvalds
2003-12-02 18:45           ` Jan-Benedict Glaw
2003-12-02 19:09             ` Linus Torvalds
2003-12-02 19:13               ` Jan-Benedict Glaw
2003-12-02 19:39               ` Gene Heskett
2003-12-02 20:13                 ` Jeff Garzik
2003-12-02 20:32                 ` Stephan von Krawczynski
2003-12-02 21:48                   ` Gene Heskett
2003-12-02 21:56                     ` Linus Torvalds
2003-12-03  2:36                       ` Harald Arnesen
2003-12-03  9:21                     ` Helge Hafting
2003-12-02 19:59           ` snpe
2003-12-02 22:30             ` Mike Fedyk
2003-12-02 22:43               ` Arnaldo Carvalho de Melo
2003-12-03 14:08                 ` snpe
2003-12-03 13:26                   ` Christoph Hellwig
2003-12-02  8:18       ` Christoph Hellwig
2003-12-01 15:26 ` Norberto Bensa
2003-12-01 23:30   ` 2.6 security patches merged? was: " Mike Fedyk
2003-12-02  0:06     ` Chris Wright
2003-12-02  0:58       ` Måns Rullgård
2003-12-02  1:56         ` Chris Wright
2003-12-02 11:55     ` Marcelo Tosatti
2003-12-02  9:00   ` Matthias Andree
2003-12-02 11:54   ` Ionut Georgescu
2003-12-02 12:03     ` Arnaldo Carvalho de Melo
2003-12-02 13:13       ` Ionut Georgescu
2003-12-02 13:38         ` Ed Sweetman
2003-12-02 14:12           ` Arnaldo Carvalho de Melo
2003-12-02 16:01           ` Ionut Georgescu
2003-12-02 16:08             ` Jeff Garzik
2003-12-02 18:20               ` John Bradford
2003-12-02 20:19               ` Ville Herva
2003-12-02 21:40                 ` Chris Wright
2003-12-02 20:09       ` Stephan von Krawczynski
2003-12-02 20:24         ` Arnaldo Carvalho de Melo
2003-12-02 20:45           ` Stephan von Krawczynski
2003-12-02 21:03             ` Arnaldo Carvalho de Melo
     [not found]       ` <Pine.LNX.4.58.0312021402360.17892@moje.vabo.cz>
     [not found]         ` <20031202131512.GU13388@conectiva.com.br>
     [not found]           ` <Pine.LNX.4.58.0312021433360.8417@moje.vabo.cz>
     [not found]             ` <20031202135423.GB13388@conectiva.com.br>
2003-12-02 20:21               ` Tomas Konir
2003-12-02 18:53                 ` Mike Fedyk
2003-12-02 19:06                   ` Valdis.Kletnieks
2003-12-02 23:13                 ` Jose Luis Domingo Lopez
2003-12-03 18:22                 ` bill davidsen
2003-12-04  1:24                   ` jw schultz
2003-12-04  1:47                     ` Mike Fedyk
2003-12-04  3:45                       ` Tim Connors
2003-12-04  5:41                         ` Willy Tarreau
2003-12-05  0:14                       ` jw schultz
2003-12-01 15:56 ` Marcelo Tosatti
2003-12-01 21:02 ` David S. Miller
2003-12-03 21:26 ` Jan Rychter
2003-12-03 20:51   ` Jeff Garzik
2003-12-03 21:14   ` Willy Tarreau [this message]
2003-12-05 15:33   ` John Jasen
2003-12-05 22:23     ` Mike Fedyk
2003-12-06 15:49     ` Max Valdez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031203211449.GB11325@alpha.home.local \
    --to=willy@w.ods.org \
    --cc=jan@rychter.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).