From: Willy Tarreau <willy@w.ods.org>
To: Rene Rebe <rene.rebe@gmx.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: linux-2.4.22 released
Date: Tue, 26 Aug 2003 18:11:49 +0200 [thread overview]
Message-ID: <20030826161149.GA25064@alpha.home.local> (raw)
In-Reply-To: <20030826.151903.640928788.rene.rebe@gmx.net>
On Tue, Aug 26, 2003 at 03:19:03PM +0200, Rene Rebe wrote:
> Hi,
>
> On: Mon, 25 Aug 2003 15:23:58 +0200,
> Matthias Andree <matthias.andree@gmx.de> wrote:
> > On Mon, 25 Aug 2003, Marcelo Tosatti wrote:
> >
> > > - 2.4.22-rc4 was released as 2.4.22 with no changes.
>
> I would like to vote for i2c-2.8.0 ...
Well, there are two types of patches/add-ons out there :
- those which always apply very well and very easily : ALSA, i2c, ...
- those which are very sensible to frequent core changes : VM, FS, ...
ACPI and IDE were of the later type, and were included lately, one at a time.
This greatly eased the production of "alternative" kernels, because most others
were really easy to add.
Considering that Marcelo will never apply everything at once, would you find
more interesting that he merges difficult parts once, and let the easy ones to
all of us, or that he merges only the easy parts and let us have a hard time
merging the rest every time a new pre-release goes out ?
If I had the choice, I'd rather merge ALSA, i2c and friends myself, and rely on
a correctly merged VM or XFS or whatever. When you compile ALSA or i2c for your
kernel, you don't even notice that they touch the kernel, so what's the
problem ? We're not *that* lazy !
As a final note, I would say that this even increases test coverage : let's
assume that 1% of us replace the VM, while 20% add i2c. Then including i2c
will lead to 100% of us testing it and 1% of us testing the VM. On the other
hand, merging the VM into mainline whill lead to 100% of us testing it and 20%
of us testing i2c. Which case do you think is more reasonable for stability ?
Regards,
Willy
next prev parent reply other threads:[~2003-08-26 16:16 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-25 11:48 Marcelo Tosatti
2003-08-25 8:11 ` Enrico Demarin
2003-08-25 13:23 ` Matthias Andree
2003-08-25 13:32 ` Christoph Hellwig
2003-08-25 13:35 ` Ramón Rey Vicente
2003-08-25 21:13 ` J.A. Magallon
2003-08-25 22:22 ` Adrian Bunk
2003-08-26 0:21 ` Ramón Rey Vicente
2003-08-26 21:49 ` Diego Calleja García
2003-08-26 21:55 ` Adrian Bunk
2003-08-26 22:29 ` Diego Calleja García
2003-08-27 2:15 ` Ramón Rey Vicente
2003-08-27 5:21 ` Gerardo Exequiel Pozzi
2003-08-27 1:20 ` Chuck Campbell
2003-08-27 1:48 ` David van Hoose
2003-08-27 1:55 ` David van Hoose
2003-08-27 3:28 ` Kurt Wall
2003-08-27 2:01 ` Ramón Rey Vicente
2003-08-27 4:12 ` Willy Tarreau
2003-08-26 22:29 ` Matthias Andree
2003-08-27 9:47 ` Bas Mevissen
2003-08-26 13:55 ` Matthias Andree
2003-08-25 13:38 ` Nick Piggin
2003-08-25 22:34 ` Bill Davidsen
2003-08-25 14:38 ` Yann Droneaud
2003-08-25 15:35 ` Krzysztof Halasa
2003-08-25 16:03 ` Luca Montecchiani
2003-08-25 19:18 ` Erik Andersen
2003-08-25 20:00 ` Edesio Costa e Silva
2003-08-25 20:10 ` Tom Rini
2003-08-26 13:19 ` Rene Rebe
2003-08-26 15:00 ` Alan Cox
2003-08-27 3:47 ` CaT
2003-08-26 16:11 ` Willy Tarreau [this message]
2003-08-26 19:32 ` Greg KH
2003-08-26 1:52 ` cryptoapi doesn't build Tom Vier
2003-08-26 10:23 ` James Morris
2003-08-27 21:49 ` Tom Vier
2003-08-27 22:03 ` Marc-Christian Petersen
2003-08-26 4:25 ` [PATCH-2.4] make log buffer length selectable Willy Tarreau
2003-08-27 20:09 ` Tom Rini
2003-08-27 20:48 ` Willy Tarreau
2003-08-25 16:25 linux-2.4.22 released Mikael Pettersson
2003-08-25 16:40 ` Marc-Christian Petersen
2003-08-25 16:53 Marcelo Tosatti
2003-08-25 17:20 Mikael Pettersson
2003-08-27 21:45 ` Marc-Christian Petersen
2003-08-26 22:25 John Bradford
2003-08-27 2:11 ` Ramón Rey Vicente
2003-08-27 6:10 John Bradford
2003-08-28 2:31 ` bill davidsen
2003-08-27 11:10 Vid Strpic
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=20030826161149.GA25064@alpha.home.local \
--to=willy@w.ods.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rene.rebe@gmx.net \
/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
Powered by JetHome