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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
