>
> Hi,
>
> I suggest to make a linux/patches/ directory where bigger 3rd party
> patches can be stored. I think of things like devfs (as long as it isn't
> part of the official kernel - bu I hope it will be merged soon), my
> boot logo selection patch and other improvments which are not included
> until now (becouse linus didn't have anouth time or just doesn't like
> the patch but it still may be usefull for some people).
>
> My idea is that we could have in this directory to files per patch:
>
> <patchname>.patch which is the actual patch and
> <patchname>.txt which conatins a description and a header with well
> defined entries (like kernel version it was written
> for and applies clean).
>
> This archive could be maintained by someone else than linus and the newest
> version could be downloaded from some website
This seems like a good idea.
> - but it should be part of
> the kernel tarball or at least should be distributed together with the
> linux kernel (like linux-2.1.124.tar.bz2 and patches-2.1.124.bz2) from
I'm not sure about that. I would have thought that would make it look far
more 'official' than it really is. Certainly there should be some mention
of the website in the kernel documentation somewhere. Also, if the
patches are distrbuted with the kernel, the Linus has to wait for all the
people who have contributed patches to update their patches for the new
kernel before he can release it.
> IMHO there are three cathegories of patches:
>
> 1.) Bugfixes
>
There are bugfixes (quick and dirty style - it works, but is ugly/slow/the
wrong way of doing it) and bugfixes (the correct solution)
The second type obviously should go straight into the kernel tree and
aren't a problem. But the quick and dirty fixes should have a home so
that people can fix bugs without having to download an entire patch.
> 2.) Improvements (like support for up to 1.000.000 processes)
>
> 3.) New features (like support for a new filesystem or network card)
>
> This patch-archive is thouth for 2. and 3. patches. For patches of the
> cat. 3 it can be something like "really experimental" or just becouse it's
> not possible to disable the whole patch useing an configuration option
> (like it is with devfs). Patches of the cat. 2 are probably only usefull
> for a little number of users - but they really need it and if we
> distribute the patch together with the kernel we tell everyone that it is
> possible to do this (imho this is an importand point).
>
Is it too much to expect people to look at a web page on the off-chance
that somebody has written a patch to do what they need to do?
All IMHO, of course.
-- Mike <rickettm@ox.compsoc.net>Half a mind is a terrible thing to waste!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/