Re: Ralink RT2500 54g wireless for inclusion?

[Horms <horms@debian.org>]

On Thu, Oct 27, 2005 at 09:21:39AM +0200, Sven Luther wrote:
> On Thu, Oct 27, 2005 at 01:32:03PM +0900, Horms wrote:
> > On Thu, Oct 27, 2005 at 12:51:06AM +0200, Sven Luther wrote:
> > > Well, the problem is that the outside-of-tree modules are rather a pain to us,
> > > since we have no good procedure for kernel abi changes and outside-of-tree
> > > modules, and it requires more work to maintain them, and it is difficult to
> > > find good maintainers for those packages.
> > 
> > That is preceicely the reason code should be merged upstream,
> > not patched onto the Debian kernel. Do you want to wear that pain?
> 
> Well, my impression is that code like that will make it upstream in any case,
> it is a plain driver and many people are using it. it may not be upstream yet
> for a variety of reasons, like the code not being quite top-notch yet, or the
> maintainer not really having the strength or the knowledge to do it right, or
> it being at odd with the upstream release plans or whatever. This is i believe
> a temporary issue, and differs from other wide-ranging patches which will
> never make it upstream and can create a lot of brokeness, and which we will
> have to maintain forever.
> 
> Furthermore, us having it in our tree may help testing it, and facilitate
> upstream integration or such.
> 
> So i think our policy of "if it is not upstream, we won't take it", may be too
> extreme, especially for stuff like this, which are drivers for hardware our
> user need, and especially for drivers done by licencing-friendly companies
> like ralink, we should push it more strongly, as a position statement or
> something.

I think that if you believe the driver will go upstream, 
and are willing to maintain it for Debian in the mean time,
that is fine. Though I guess it may have to be removed
if ultimately upstream rejects it.

The idea of the upstream=good policy is to try and a) help upstream
as much as possble by not randomly forking, and thus having bug
reports that are of value to them and b) not have us running around
in circles maintaining extra code - we already have far to much
on our plate as it is.

So if code does look like it will go upstream, and its self contained,
its probably good enough to meet the guidlines. This seems
to be a good case of that, though it still needs someone
on the Debian side to take care of it. I guess that's you :)

-- 
Horms