<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/1.1.9">
</HEAD>
<BODY>
I don't know if I'm champion material right now, as I'm pretty close to being over-committed. I'll have to give this some thought. I had guessed that this would be a no-brainer since the device is fully supported under RH9 (heard this from cow-orker, not confirmed) and managed to get into 2.5.x.. <BR>
<BR>
If I were to bug the vendor to donate hardware, who gets it and where does it get sent?<BR>
<BR>
-Randy<BR>
<BR>
On Thu, 2004-01-22 at 00:24, Pete Zaitcev wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373" SIZE="3"><I>On Wed, 21 Jan 2004 22:39:10 -0600
Randy Zagar <jrzagar@cactus.org> wrote:
> The attached patch files include changes to the kernel-2.4.spec file and
> a patch file from the vendor:
>
> </FONT><A HREF="http://www.keyspan.com/support/linux/files/currentversion/patch/"><FONT SIZE="3">http://www.keyspan.com/support/linux/files/currentversion/patch/</FONT></A>
<FONT COLOR="#737373" SIZE="3">
I always turn such things down unless there's an overriding reason to
include them. Every patch, no matter how correct or benign, adds maintenance
burden. IMHO, it is even more justified in case of Fedora, because of
Fedora's short release cycle.
The correct way to handle this patch is
1) to identify a champion for the issue. Sometimes it's a user, but
often a vendor. If Keyspan cannot be arsed to
perform the rest of the steps, users have to step in.
2) to file upstream, in this case linux-usb-devel
3) track the rest
I can fill in as a champion for many issues USB, but not all.
If I had the hardware, I might have.
The patches appear to be a backport of what is present in 2.6 already,
so there should not be a problem passing linux-usb-devel and Greg Kroah.
-- Pete</I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>