> I really appreciate your feedback but you seem to prefer writing
> mails instead of trying what I wrote. [Mika]
Because 2.6.21 is not going to help us even if it works; I need more
data; it's not the only test; and Linux ++ fixes anything but is not a
distro. My users need grml repos, 0.9 or 1.0. They can't function with
2.6.21. Communication & research is all that's possible anyway.
Memorial Day vacation - I'm packing now. (Incidentally: verified as
kernel regression under Ubuntu 7.04; same problems.)
During beta I would have done as requested to improve 1.0 final. Grml
gave me no task, no suspect kernel config flags to isolate, etc. Radio
silence made me hungry for info-crumbs...
But a broken (from our standpoint) final release makes me ask how grml
beta cycles are supposed to work. I just need to know what grml
does/thinks so I can work with, or around the philosophy & constraints
involved.
Beta cycles are meant to catch bugs before release. Kernel regression
is just another bug category. A kernel regression which, for instance,
broke your laptop, would prevent a grml release. And that is how it
should be.
Re bisect: Other people do that coordinated by -stable. My job is
sysadmin, not kernel dev. The whole point of Linux for us, rather than
BSD or Open Solaris or Nexenta or whatever, is hardware support. If we
have to become kernel devs too, supporting/debugging our own hardware,
then we would consider other kernels to develop, with possibly more
rational code. Note about USB in Linux, "the in-kernel USB interfaces
have undergone at least three different reworks over the lifetime of
this subsystem" (Greg Kroah-Hartman). Anyway it's not my call. The
last thing my boss will allow is debugging Linux hardware drivers.
What I'm asking is, do you inspect a grml bug report, and then talk to
-stable to see if they have anything related in their pipeline, and then
decide whether grml should wait for a patch?
Looking at -stable patch-2.6.20.12, I see USB fixes relating to mutexes,
IRQs, etc. - the big stuff.
What -stable version is 2.6.20-grml in grml 1.0 final?
Next, how does Debian fit into all this? Grml tracks Debian unstable.
But grml releases are tied to Linus's kernel releases, not Debian kernel
work, right? Correct me on anything.
Does grml kernel customization include the possibility of using a
-stable release that is not yet incorporated into Debian? Or is Debian
a limiting factor?
Dumb question maybe, but if I compile my own 2.6.20-x using grml source
and patched from -stable, will it work with grml 2.6.20-grml repos? I'm
willing to compile a kernel but if I start having to build repos too,
I've already become a custom distro, and I'd rather not.
Thanks - see you a week from now.
Mark
