|
On 2000-11-21T09:41:06,
Joseph Mack <mack.joseph@xxxxxxx> said:
> RedHat has created a situation which makes them money and stops
> others from working on LVS. Any problem from a person
> with RedHat - can't compile, can't find modules, doesn't work,
> I have to read through and think about. I then have to make a reasonable
> guess as to whether this is a RedHat induced problem or a real problem.
I wouldn't have any problem if the default response to a bugreport from a
person using a distribution kernel would be "talk to your vendor or repatch
your own kernel from ftp.kernel.org", if it appears to be related to that.
That is a reasonable stance to take. The kernel people already do that.
> you don't agree that this is a large load and has erased any good will
> I had towards RedHat?
Well, I can't argue with that obviously, you will know better how you feel
than I do.
> This is why patches that change between kernel releases should be
> treated differently. LVS has been releasing about 2 versions for
> each kernel release for 2 yrs now.
It is _impossible_ to treat that that differently. They ship as part of the
distribution kernel, if you need an update to that before the next official
release, you are on your own.
This is how distributions have always handled this. (The SuSE support database
has hints how to rebuild kernels which work with the distribution, but support
itself is voided unless you have a special support contract)
That makes it all the more important to make LVS part of the shipped kernel,
so people can receive official support from the vendors and the vendors have
to be able to reproduce the problem and certify the kernel as a whole in the
first place.
> > If the distribution shipped reiserfs included, and they tried to patch
> > a newer release of reiserfs into that, that will break too.
> Does reiserfs have full releases between kernels?
Yes.
> If so what do the people who answer questions in their own time about
> reiserfs think about including it in the distribution?
There usually isn't a problem with that. Frankly, I am quite amazed why the
inclusion of LVS into RH's default kernel has created such a load - it
shouldn't be the case.
> I didn't know that individual distributions have that many patches.
> I've assumed that if the standard kernel is good enough for Linus and for
> me then it is good enough for most of us.
This isn't quite true. Distributions all have additional bugfixes, features
(for large machines for one), filesystems (reiserfs, ext3...) which haven't
been accepted into Linus' kernel when the distribution was build.
> How many of these patches are from projects that have production releases
> between kernels.
> How many of them are small (<10 lines) bug fixes?
I don't have the numbers for these.
> > so we have to include it in our kernel.
>
> could you put the patches in a contrib directory and have the patch applied
> as part of the build?
Well, thats what happens. It is applied as part of the build. You _could_
download the src.rpm, swap patches, and rebuild the kernel package. However,
this will take quite some effort (ie merging the patches et al), and also most
kernel RPMs are setup to build much more than just a single kernel.
So they could just as well go ahead and rebuild the kernel with the patches
they need from kernel.org anyway.
> > Having LVS included will work fine for most people
>
> it's the other people that I'm concerned about.
There will always be people who can't get it right. The LVS install file
should tell people
"Hey, if you are getting an error message like this, or if your
distribution already includes LVS, don't try applying the patch on top
of it.
First, try checking with your Linux vendor whether an updated kernel
package with full support is already available.
If you think this revision of the LVS patches provides significant
improvement over the previous ones, or fixes a critical bug for you,
and the vendor doesn't yet provide an updated kernel, please ask them
to do so.
If you need a newer revision than what your distribution supplies,
please grab a clean kernel tree from kernel.org and start from that.
Make sure to apply all other patches you need! "
Do you think this would help?
> LVS has been production level for 2 yrs now, there is no sudden change in
> the quality, reliability or functionality of the LVS code just because it
> has gone to 1.0.0.
Exactly. So there _isn't_ a pressing reason why people who are unable to
should upgrade.
> Rather than SuSE easing the lives of its purchasers, I'd rather SuSE
> first minimised its impact on people developing the software that SuSE uses
> and who are doing it in their spare time.
We do have to balance both. And I don't see a conflict.
But you are essentially asking for vendors not to include any patch on top of
the plain kernel, which just will not work.
> there has only been 1 or 2 of these in the last 2 yrs. This is not a
> significant factor in deciding how to use LVS.
If there isn't a signifcant reason why people should upgrade, they can either
continue to use the distribution supplied kernel - which will most likely work
fine, I have systems in production for almost 1-2 years now without having
needed an upgrade - or go through fetching a kernel upgrade from kernel.org.
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
Development HA
--
Perfection is our goal, excellence will be tolerated. -- J. Yahl
|
