From: Hans Reiser <reiser@namesys.com>
To: Hubert Mantel <mantel@suse.de>
Cc: "Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>,
reiserfs-list@namesys.com
Subject: Re: when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?)
Date: Wed, 05 Feb 2003 00:45:44 +0300 [thread overview]
Message-ID: <3E403488.9050408@namesys.com> (raw)
In-Reply-To: <20030204163609.GT19723@suse.de>
Hubert Mantel wrote:
>Hi,
>
>On Tue, Feb 04, Hans Reiser wrote:
>
>
>
>>A Marcelo kernel is NOT a randomly patched kernel. It is the OFFICIAL
>>kernel that the community has picked to be the official kernel. SuSE
>>and RedHat should be team players, and act accordingly.
>>
>>
>
>SuSE and Red Hat cannot use the official kernel, because it falls apart in
>certain scenarios and is lacking lots of features and drivers.
>
>All the needed fixes and features are available. I would be happy if all
>this stuff would be in the official kernel, so I would not need to
>maintain several hundreds of patches.
>
Has Namesys just been lucky in regards to how responsive Marcelo has
been for us? In my interactions with him, he has never once
unreasonably rejected a patch or ignored a patch.
>
>
>
>>Linebackers should defend the quarterback, or convince the rest of the
>>team to get a different quarterback.
>>
>>
>
>Sorry, I don't understand a single word in this sentence.
>
Sorry about the american football reference (quarterbacks are the team
strategists and the players who most often have the ball, linebackers
are guys who among other things keep him from being tackled (being
tackled while you have the ball is bad)).
The ability to download the latest official stable kernel is one of the
great things about Linux. There are times when the latest official
kernel is behind SuSE or RedHat, and there are times when it is ahead,
as a result of different release schedules if nothing else.
It seems that what RedHat puts on its Advanced Server CD is a kernel no
reiserfs user would want to use if he had a choice. What SuSE has put
on its CD is at the moment probably a faster and more stable for
reiserfs kernel than the official kernel (I hope we will change that
soon, but....). ReiserFS is just one kernel feature, and what is best
for users is going to vary all over the place. Sometimes the distro
kernel is more advanced for some feature, sometimes the official kernel
is more advanced.
If we as a community fragment for the purpose of experimenting, then it
is healthy. However, there needs to be one kernel branch that the
entire community backs up and says "we stand behind this except when we
are motivated by its specific flaws for the particular user in question
to not do so".
Maintainers need to be able to send their patches to Marcelo, and know
that now they can tell any Linux user of any distro to just upgrade to
the latest official stable kernel and case closed.
Consider my situation with the user of the RedHat 2.4.9 based kernel,
because it has the advantage of not being a SuSE related problem.;-)
ReiserFS users should not use a 2.4.9 based kernel, they should use
2.4.18 or later. It is wrong that RedHat won't support him if he
upgrades to the official kernel. In this case, the official kernel is
more advanced for his needs. It removes one of the great advantages of
the open source methodology compared to proprietary OSes if he can't
download kernels from the net. What should I say to him (other than
switch his whole distro to SuSE;-) )?
The official kernel is our kernel community's only chance to overcome
its fragmentation. We need to support it. All of us, regardless of
what camp we are in. It should never be the discouraged officially
unsupported branch of the kernel (except when specific flaws relevant to
the usage of the user in question are present, and even then it should
be with an attitude of "the patch you need isn't yet in the official
kernel, try the distro kernel and things will work").
Let's all work as a team.
--
Hans
next prev parent reply other threads:[~2003-02-04 21:45 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-30 16:35 reiserfs on redhat advanced server? Jure Pecar
2003-01-30 17:30 ` Vitaly Fertman
2003-01-30 19:16 ` Hans Reiser
2003-01-30 22:41 ` Ragnar Kjørstad
2003-01-31 11:39 ` Hans Reiser
2003-01-31 11:53 ` Lars Marowsky-Bree
2003-01-31 12:08 ` Alexander Lyamin
2003-01-31 12:20 ` Hans Reiser
2003-01-31 12:29 ` Lars Marowsky-Bree
2003-02-01 10:09 ` Alexander Lyamin
2003-01-31 12:29 ` Yury Umanets
2003-01-31 15:22 ` Valdis.Kletnieks
2003-01-31 12:10 ` Hans Reiser
2003-01-31 12:21 ` Lars Marowsky-Bree
2003-01-31 12:35 ` Hans Reiser
2003-01-31 12:39 ` Lars Marowsky-Bree
2003-01-31 13:06 ` Oleg Drokin
2003-01-31 13:55 ` Chris Mason
2003-01-31 13:58 ` Russell Coker
2003-01-31 14:14 ` Chris Mason
2003-01-31 14:23 ` Hans Reiser
2003-01-31 14:20 ` Hans Reiser
2003-01-31 14:45 ` Russell Coker
2003-01-31 14:08 ` Oleg Drokin
2003-01-31 14:23 ` Chris Mason
2003-01-31 16:16 ` Brian Tinsley
2003-01-31 14:15 ` Hans Reiser
2003-01-31 14:23 ` Ookhoi
2003-01-31 14:37 ` Chris Mason
2003-01-31 15:00 ` Russell Coker
2003-01-31 15:22 ` Chris Mason
2003-01-31 16:21 ` Russell Coker
2003-01-31 18:03 ` Dieter Nützel
2003-01-31 18:32 ` Hans Reiser
2003-01-31 12:40 ` Oleg Drokin
2003-02-01 10:58 ` Alexander Lyamin
2003-02-03 12:38 ` Juan Quintela
2003-02-03 14:20 ` when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?) Hans Reiser
2003-02-03 14:53 ` Chris Mason
2003-02-03 18:51 ` Hans Reiser
2003-02-03 19:18 ` Valdis.Kletnieks
2003-02-03 19:38 ` Hans Reiser
2003-02-03 19:32 ` Chris Mason
2003-02-03 19:50 ` Hans Reiser
2003-02-03 20:34 ` Lars Marowsky-Bree
2003-02-04 1:55 ` when distros do not support official Marcelo kernels they are not being team players Matthias Andree
2003-02-04 2:24 ` Valdis.Kletnieks
2003-02-04 2:35 ` Brian Tinsley
2003-02-04 2:41 ` Chris Mason
2003-02-04 2:56 ` Matthew Johnson
2003-02-04 3:54 ` Matthias Andree
2003-02-04 16:27 ` Hubert Mantel
2003-02-04 4:03 ` Matthias Andree
2003-02-04 10:09 ` Hans Reiser
2003-02-04 11:17 ` Matthias Andree
2003-02-04 3:32 ` Matthias Andree
2003-02-03 20:40 ` when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?) Chris Mason
2003-02-04 0:46 ` Hans Reiser
2003-02-04 2:02 ` Chris Mason
2003-02-04 9:53 ` Hans Reiser
2003-02-04 13:46 ` when distros do not support official Marcelo kernels they are not being team players Juan Quintela
2003-02-04 16:36 ` when distros do not support official Marcelo kernels they are not being team players (was Re: reiserfs on redhat advanced server?) Hubert Mantel
2003-02-04 20:55 ` Valdis.Kletnieks
2003-02-04 21:47 ` Hans Reiser
2003-02-04 21:45 ` Hans Reiser [this message]
2003-02-04 22:22 ` Chris Mason
2003-02-04 22:57 ` Hans Reiser
2003-02-06 18:06 ` Bernd Schubert
2003-02-05 8:34 ` Hubert Mantel
2003-02-05 12:04 ` when distros do not support official Marcelo kernels they are not being team players Juan Quintela
2003-01-31 12:35 ` reiserfs on redhat advanced server? Oleg Drokin
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=3E403488.9050408@namesys.com \
--to=reiser@namesys.com \
--cc=mantel@suse.de \
--cc=reiserfs-list@namesys.com \
--cc=reiserfs@ragnark.vestdata.no \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.