2.3.51 tulip broken

[Jeff Garzik]

Chris Higgins wrote:
> 
> >
> > As has been pointed out many times, change management in the stable
> > series is incredibly important.  You simply cannot blanketly update a
> > popular driver like tulip, you must incrementally update it, so that
> > changes can be evaluated carefully.  Donald is not perfect, and his
> > newer drivers do not work at all for some people.
> 
> Whatever about the religous nature of the preceding flurry of emails,
> I have to disagree with you here...
> 
> Are you saying that a driver update which contains 4 changes, has to
> go through as 4 seperate patches, with a delay between each of them
> so "that changes can be evaluated carefully" ? That has to be both daft and
> a waste of time...

It must be balanced.  Both extremes are daft :)  Big updates to popular
drivers, containing lots of changes, are equally untenable.


> > > Tulip development is such a huge issue that it has it's own list and discussion of
> > > the drivers is encouraged there.  Same goes for cards like the eepro.  There has
> > > been a -lot- of public discussion regarding a -lot- of the changes.
> >
> > Sure discussion occurs.  I don't see frequent updates appearing on
> > Donald's web site, nor do I see discussion of Donald's net driver core
> > changes on any mailing list [except when I flame him of course].
> 
> Donald has been making the Tulip chipsets dance for a very long time,
> I don't think that anyone can raise issue with his committment to the
> open-source cause.
> 
> Just because you don't like the way in which he does it - does not
> give you any right to 'flame' him...  I'm more than happy to let
> Donald get on working on the code in whatever timescale he can..
> I don't worry that he's forgotten about it, but I understand that
> he has more to do in his life than work / tulip development...

Sure.  But the facts of the situation are that updates were not
occurring for the 2.3.x drivers, before I started doing them.  A few
drivers, like eepro100, were getting updated by outsiders, but not
many.  And none to the currently-stable levels of the 2.2.x series,
which gets the majority of bug reports and fixes.

I don't care how Donald works or what he does when he works.  I care
about the Linux kernel.  And when net drivers go unmaintained for a long
time, something needs to happen.


> If you disagree with his approach, then take on the responsibility
> yourself... take the grief / crap that everyone contributing to the
> open source cause gets (the sort of stuff that you are throwing)

Um, please read the entire thread, take a look at Linux kernel
development.  I currently maintain the tulip and rtl-8139 drivers in the
2.3.x kernels, and many other net drivers have also been updated by me
in recent kernels (softnet and hotplug updates and bug fixes, for
example)

I _am_ taking the responsibility, because no one else is doing so.


> 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.

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.


> > If changes are not regularly pushed out to the Linus tree, then you miss
> > important bug reports.  The people on linux-tulip, and the people who
> > use the driver's on Donald's web site, are SELF-SELECTED, and represent
> > the minority of all Tulip users.  This is not adequate enough testing to
> > ensure that a massive update will be bug-free for the users at large.
> 
> But - they are the people who are doing 'wierd' things with the tulip
> code, and stick very close to the latest revision of the code... to
> they get to 'alpha' test it before it goes mainstream...

Incorrect.  In the case of the big tulip update, these are people for
whom tulip driver has always worked, and then after the update, it
doesn't.  This is all well-documented on linux-kernel and elsewhere.

	Jeff



-- 
Jeff Garzik              | My to-do list is a function
Building 1024            | which approaches infinity.
MandrakeSoft, Inc.       |
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org