[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: kernel modules in extras criteria



On Thu, 2006-08-03 at 15:27 -0400, Dave Jones wrote:
> On Thu, Aug 03, 2006 at 01:18:19PM -0600, Kevin Fenzi wrote:
>  > Questions:
>  > 
>  > - Should a kernel module where the upstream has no plans of merging
>  > with the upstream kernel be allowed in extras? (This means it could
>  > stay around in extras forever)
>  > 
>  > - If upstream says they are going to try and merge their module, but
>  > never does (lack of time, technical issues, no real desire to, etc),
>  > should the module be removed after some time?
>  > 
>  > - Should there be any other criteria? (renew approval every new
>  > release, only allow modules for 1 year and remove, etc)
> 
> - Who fixes the inevitable bugs that get reported ?
> 
> I'll state this publically now: If I get Fedora kernel bugs filed,
> and they have modules loaded that aren't shipped as part of the
> kernel rpm, I am _completely_ uninterested in dealing with those bugs
> unless they can be shown to be present without them loaded.
> This is regardless of whether they're 100% opensource or not, it comes
> down to time.  I don't have time to deal with all the bugs we have
> *today*, and I for sure don't have time to go running around grabbing
> the sources for out of tree modules.

As an intellectual exercise, (partly to learn more about git, partly to
learn more about the kernel, and partly to see how hard it would be)
I've set up a clone of the kernel git repository with the Zaptel drivers
patched in.  I have made the bare minimum of changes to get the code to
compile (mostly include file locations).  As time goes by I may weed out
#ifdef'd compatibility code.  Now, being new to both git and kernel
development I'm sure that I've made some newbie mistakes, but you can
see the results here:

git://git.ocjtech.us/linux-zaptel.git

The branch is called zaptel.  Comments appreciated.  I'm not sure that I
want to maintain this indefinitely, though...

Jeff

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]