Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Saturday 08 November 2003 19:27, Eduard Bloch wrote:
> #include <hallo.h>
>
> * Robert Millan [Sat, Nov 08 2003, 05:00:07PM]:
> > On Sat, Nov 08, 2003 at 03:33:43PM +0100, Eduard Bloch wrote:
> > > Or they found a sane trade-off between optimisations and compatibility
> > > (see Wiki page below which was born in discission!). You did not
> > > discuss it. You took your own ideas as guidelines for the future kernel
> > > development.
> >
> > No, I took the ideas from the thousands of packages in Debian. How many
> > of them provide optimised binaries?
>
> Where do you see an inconsistence in my argumentation? libssl and atlas
> are examples whehere optimisations make sence, there are real jumps in
> performance. I would do the same for the kernel: pure i386 and something
> to make most users crying for optimisations happy (i686 version which is
> good for p2..4 and various k7 steppings).
>
> > > So please maintain your packages in some personal
> > > repository to not fuck up the name space (don't even think about
> > > experimental tree!) as long as we don't have a consens about it.
Please, don't be so harsh... he is using a personal repo, let's see what will
happen with this approach. I'm more curious about a kernel-policy doc and how
the patches Debian needs will be applied. Yes, I have read http://
debian.linuxwiki.de/DebianKernel/Plan (and the link to debian-installer
kernel-policy), and it is really nice, but it is needed to be assembled as a
complete kernel-policy (like perl-policy). I'm especially curious of how the
missing functionallity in vanillas, but needed by Debian will be handled,
e.g. when separate patch packages will be created and when the tree will be
patched by default (yes I know Herbert's criteria by heart), will upstreams
be pushed to approve/accept these changes or will not. Then when you have the
procedure cleared up it is more clear how to implement the things up. Glibc
has Maintainer: GNU Libc Maintainers Team and debian-glibc@lists.debian.org
and I guess debian kernels needs a team and ml too. Let's do the first things
firts.
--
pub 4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu>
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Reply to: