> > One of the issues with Linux, is that it's huge popularity has brought
> > with it a whole load of glory hunters, who will be here in kernel space
> > today , and gone tomorrow off chasing some new 'world saviour'... unless
> > we apply a calm steading hand to the helm we run the risk of driving the
> > Linux ship onto the rocks...
>
> Write all the poetry you want. :) You still cannot argue with the fact
> that net drivers were not getting updated, because Donald's method of
> development and the Linux kernel method of development are increasing
> incompatible.
>
> You can do cathedral development for one driver, or two. No problem.
> But maintaining a large number of the most popular net drivers means you
> are leaving people in the lurch for months at a time. During a kernel
> development series, that creates a fundamental problem. If a net core
> change occurs which breaks net drivers, as happened during 2.3.x, the
> most popular net drivers remain broken and completely unusable until
> Donald updates all of them.
Hang on a sec... let's take a very simplistic look at the timeline.
a/ At some point the tulip driver set was working happily.
b/ Lots of people use tulip cards, and the tulip driver
so the tulip driver becomes one of "the most popular drivers".
c/ Changes are made to the kernel core which breaks the drivers
At this point, we seem to differ on our expectations of Donald's
role.. You have the view, that Donald should follow the kernel path
and adjust the drivers to match the new design model, and some others
have the view that Donald should continue with the development
schedule he's working with.
I think that there is some merit in both viewpoints, but that ultimately
as he is giving of his own time - it's Donald's decision as to which
choice he makes.
One might ask the equally valid question - why did the kernel development
release deviate and create a 'fundamental problem' without the kernel
developers ensuring continued compatability of 'the most popular net drivers'.
You might argue that they tried to get Donald to re-code the driver, but
the point is that they made the change - and broke the driver..
I don't think (and I believe most people will agree with me) that it's
fair to expect contributors to work to anyone else's schedule... If the
changes are planned far enough in advance - then there should be enough
time for the integration to happen - or for someone else to do up a
copy of the driver themselves... but to push ahead with fundamental changes
because that may be the only way to force the issue is daft... It's the
sort of thing you'd expect to find from M$soft... (you have to upgrade
because it's not backward compatible)...
>
> It is not fair for users to expect Donald to update and test everything
> immediately, but nor is it fair for hackers and users of devel kernels
> to wait MONTHS until a suitable fix for all his drivers is available.
> That impedes the progress of the entire kernel.
Open source - fix it yourself :) Or purchase a support contract from
Donald :)
It's the up-side, and the down side of the design model...
I'm not suggesting that you don't understand the issues, and it is
clear that you are extremely frustrated in trying to do the 'right thing'
for the kernel - but unfortunately this is the way the cookie crumbles...
it only works if everyone plays ball... there is a certain amount of onus
on the kernel developers to make sure that backward compatability exists -
or to accept clearly the impact of breaking things.. in this case
it's broken..
Chris
> Jeff
> --
> Jeff Garzik | My to-do list is a function
> Building 1024 | which approaches infinity.
> MandrakeSoft, Inc. |
-- * Chris Higgins, IT Manager, Esat Net chris@esat.net * * Phone:+353-1-2166300 Fax:+353-1-6703972 http://www.esat.net *- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Mar 20 2000 - 15:04:22 EST