|
Lars Marowsky-Bree wrote:
>
> On 2000-11-20T14:54:51,
> Joseph Mack <mack.joseph@xxxxxxx> said:
>
> > Probably the single most often questions asked here are based on wierd
> > errors that come from people doing multiple patches and not understanding
> > what they've done.
>
> People not reading manuals will not be easily cured.
knowing this we should minimise the opportunities for and consequences
of any mistakes they do make.
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.
Presumably as the obvious problems get solved, it will be harder to
separate the obscure problems from those added by distributions.
Eventually fixing problems with LVS will stop and we'll only be dealing
with distribution added problems.
> > This is a large load on the mailing list and has stretched my patience
> > with RedHat.
>
> I don't agree -
you don't agree that this is a large load and has erased any good will
I had towards RedHat?
> what these people do will not work for _any_ patch, not just
> LVS.
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.
> 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?
If so what do the people who answer questions in their own time about reiserfs
think about including it in the distribution?
> > I really would like you to reconsider this. Having 2 distributions that
> > don't work for LVS would be more than I could bear. Could you instead
> > include in the menuconfig scripts a routine that applies an LVS patch -
> > anything
> > that will allow someone to patch your kernel with the current LVS patch.
>
> Very unlikely. You have to understand that a kernel shipped by a distribution
> is patched with around ~100 patches or even more, so you can't "just apply" a
> patch as downloaded and expect it to fit in perfectly.
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.
I don't know the concerns and pressures that people who create distributions.
How many of these patches are from projects that have production releases
between kernels.
How many of them are small (<10 lines) bug fixes?
> It would also be a nightmare to support, and compiling a kernel with all the
> necessary patches merged on their own is beyond the ability of most users.
agree.
How many of these 100 patches are from projects with the functionality
and support required for a project like LVS?
> And we also want to have LVS available as a default component on a SuSE
> system,
no problem with that
> 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?
> Having LVS included will work fine for most people
it's the other people that I'm concerned about.
Any idea of the number of people who have got a fully functional LVS
without asking a question on the LVS mailing list? I would imagine it
is small, in which case "other" is really "most"
> and ease their lifes. LVS
> is at 1.0.0 now, so that makes a reasonable good time to include it in a
> distribution.
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.
> I would suggest that a specific comment is added to the LVS docs, about how
> you cannot just expect to be able to patch LVS into your distribution kernel
> without any problem, and that special care must be taken to make sure you
> apply and merge all the patches necessary.
we tell people to drive carefully, have sex carefully and to choose marriage
partners carefully too. If you expect the SuSE users to be careful then
you'll have to be prepared for SuSE users to find themselves
in the computer equivelant of being killed, maimed, pregnant, having AIDS
and divorced with traumatised children and paying their life savings to
wealthy lawyers. I don't want to deal with these people.
The number 1 thing with anything new, is to minimise the effect of mistakes.
It's not to maximise performance, money return... I have spent most of my life
living and working in situations with radiation, toxic chemicals, life
threatening
organisms, heavy machinery that can take your hands off, lasers that can blind,
rock climbing and spending long periods in wildernesses. Whenever I'm introduced
to a new
situation, say a milling machine, the person first tells me all the things that
can go wrong, what the effects will be, what to do if things go wrong. Sometimes
they'll tell you how to use the machine, but usually you work that out
yourself.
It's the mistakes that are important.
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.
I realise that you have to make money and that SuSE helps the Linux
community and that we need you to succeed. I will not be happy with SuSE
if you take the road that RedHat has taken here.
> The best thing for the masses really is to have the distributions provide the
> kernel with LVS included, and provide an updated kernel if LVS fixes a
> significant bug.
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.
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
