Bug#219582: ITP: linux -- Linux 2.4 kernel
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?
> 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.
If you want me to provide optimised binaries, then this is you who should go
and get the consensus. So instead of drawing your silly threats, bring up
some points and I'll gladly discuss them with you.
> Your reasoning is flawed. The packages you refer to as examples (gcc,
> libc) are maintained buy whole projects. And the do much more testing
The current Linux kernel maintainers, which provide that patchset on which my
package is based, don't do any testing?
> and they don't plan to drop parts or whole architectures with the first
> appearence of problems as you are going to do.
Someone said fixing support for some architectures properly is a "fucking
huge task". Now it is a "first appearence of problems". Would you people get
a clear idea of what the problem is?
And stop using it as an argument. If there are no up-to-date patches for one
architecture in Debian, this is a problem by itself. It doesn't have anything
to do with my package.
> > You're thinking of my package as a complete replacement for the way the Linux
> > kernel is packaged in Debian, but I think of it as an alternative.
>
> A-Ha. So there will be even more users confused, jumping between the
> traditional packages and those from you.
I understand now. Look, I'm not going to just "replace Herbert's packages".
I'm not going to solve your personal frustration with the way Herbert handles
_his_ packages, so discuss it with him not me.
> > It's not "cosmetic". The point is it has a completely different packaging
> > style and philosophy. I want to package the Linux kernel in the same way
> > the rest of Debian is packaged, that's all.
>
> As said above, this may be done this way but with 10 times more testing,
> wasting 10 times more bandwith (for frequent useles updates) and 10
> times more exotic hardware available all the time.
> [...]
> You seem to be keen on pushing "new philosophy" but at which costs?
As I said, there are advantages and disadvantages. If you don't like the
overall, don't use my package. Go back to Herbert and stop bitching me.
> > Frankly, I don't know. My packages have advantages and disadvantages, I
> > just can't expect everyone to prefer them.
>
> That's why I told you to keep them outside of Debian during the
> development.
Thanks for your suggestion, but I won't.
> > What do you mean by "kernel maintainer"? The base patchset is provided by
> > Herbert, not me. The arch-specific patches are provided by someone else, too.
>
> I cannot see many of those "someone else" being puzzled so far.
Why should they be?
> > As I said a thousand times, if an architecture is unsupportable, not
> > supporting it is an option.
>
> And as said before, your ideas are not consistent. You claim to create a
> linux-kernel package for every architecture, but only for that you like.
Erm.. don't put words in my mouth?
> Bullshit. You can fix most stuff with a initrd that includes ash-static
> or such. When you fuckup the kernel (and upload without testing as
> indicated above), there is no way to fix it unless there is human
> operator sitting in front of the box.
So, you can repair from an initrd system, but you can't load a backup Linux
kernel?
--
Robert Millan
"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."
-- J.R.R.T, Ainulindale (Silmarillion)
Reply to: