2.3.51 tulip broken

[Christopher Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Mar 18, 2000 at 11:50:58AM -0500, Jeff Garzik wrote:
> Christopher Smith wrote:
> > If you read The Cathedral and The Bazaar more carefully, you'll see
> > that ESR specifically suggests it's a good idea not to release
> > software until it's reached the stage of "plausible promise". From the
> > sounds of it, this is exactly what Donald has done. He's sat down,
> > thought about a design, and when he's got it ironed out enough that he
> > knows it's a good idea, he releases it. When he releases stuff, it's
> > not a fait accompli
> In this case, it is.  He ignored all feedback and bug reports about his
> design, which was not shared at all with linux-kernel.

I just want to make sure you are being clear with what you are
claiming: you're saying Donald released the driver but didn't share
the code with linux-kernel (the evidence before me would suggest
otherwise)? Or are you saying that feedback and bug reports he
received did not get shared with linux-kernel? The former would indeed
not be open-source, but the latter is just somebody not taking the
time to manage feedback. There's nothing in the OSD that says you have
to do that, it's just a nice thing to do if you have the time. There's
a big difference between releasing something for the world to hack on
and releasing something while trying to prevent others from working on
it. Donald clearly did the former.

> I had to come up with my own PCI probe interface before he pipes up and
> says "I've done that already."  Donald has consistently failed to work
> with other kernel developers.

So, your real complaint about Donald is not that he isn't doing open
source development, but that he doesn't play nice with the other
kernel developers (specifically you). I'm not saying that isn't a
valid concern, I'm just saying that this doesn't give you license to
make claims about his work not being "open source".

Now, I think you can certainly say that Donald isn't interacting
enough with the outside world. Rather than slandering him, focus on
dealing with the problem (which, from the sounds of things you're
doing with at least some of your time).

> > There does come a time when things need to be rewritten from scratch,
> > and when that happens, sending small patch files just isn't
> > possible. (Indeed, if small patch files were possible I'm sure by now
> > someone would have taken Donald's posted code, broken it up into
> > patches, and sent them to Linus.) I can understand why Linus might not
> > want to throw in a huge update into the kernel all of a sudden, but I
> > think it's unfortunate that some of the 100's of eyeballs out there
> > don't take a look at Donald's designs and try to understand them
> > before they prematurely dump them and come up with a quick hack.
> This is completely divorced from reality.
> 
> Donald produced a design, then ignored my feedback, Alan Cox's feedback,
> etc.
> 
> His design was dumped because it DIDN'T WORK.  Simple as that.

I'm not enough of an expert to judge whether you're right about that,
certainly there is some dispute of that claim by Donald. From what
I've observed it looks like the chief reasons his design were dumped
were because he didn't respond to e-mails. Sure there were bugs in the
specific implementation, but those can be fixed. It looks (if you look
at the patches) like a variety of patches were done, each time
changing the design, until the current design was arrived at (which
people seem to be happy with). I have to wonder if it might have been
faster/better if instead patches were made against Donald's code to
iron out bugs. Beyond subjective analysis, we'll never know.

This problem has been caused by two things: a) Donald did not have or
did not take the time to communicate his design thoroughly with other
parties and b) other parties had a hard time perceiving any value in
his design.

Now, the question is, how can these problems be resolved. Ideally, if
there was someone who could keep an open channel with Donald and yet
take responsibility for some/all of what are currently his drivers in
the kernel tree, all these problems would be resolved. In the absence
of this option, we're going to have to come up with a partial
solutions. :-(

- --Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>

iEYEARECAAYFAjjT/PgACgkQfrrCpthD+UZBbgCdE3d+M9/yKkgyp+nH2RFFCeR7
ulcAnj16vj2yXYFRd6fvkqVxZeDjh+Ew
=paBf
-----END PGP SIGNATURE-----
-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org