[Grml] Grml Beta Test Coordination

[Michael Prokop]

* Mark <27e3kk302 at sneakemail.com> [20070526 10:15]:

> > I really appreciate your feedback but you seem to prefer writing
> > mails instead of trying what I wrote.  [Mika]

[...]

> 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...

How often do I have to write this again? I had no idea where the
problem derived from.

> 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.

Just because one single device does not work anymore (notice: "broke
your laptop" is different from "my external harddisk can't be
accessed") without any relevant changes in the kernel configuration
it won't become a release-stopper for everyone out there.

> 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.

Again, you seem to prefer writing mails instead of running those
fscking 4 commands. You don't have to become a kernel dev for
installing a kernel and test it once.

> 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?

The stable-queue is available via git before being available as new
official -stable release. I track that of course to be able to
decide about kernel update/freeze.

> Looking at -stable patch-2.6.20.12, I see USB fixes relating to mutexes,
> IRQs, etc. - the big stuff.

.12 does not include anything else than a bugfix for GEODE-AES:
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.12

> What -stable version is 2.6.20-grml in grml 1.0 final?

It's all documented on http://grml.org/kernel/ - 2.6.20.11.

> Next, how does Debian fit into all this?  Grml tracks Debian unstable. 

grml is based on Debian.

> But grml releases are tied to Linus's kernel releases, not Debian kernel
> work, right?  Correct me on anything.

grml's kernel has nothing to do with the one from Debian.

> 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?

Sorry, I don't understand your question. grml and Debian regarding
the kernel are two different things.

> 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.

Everything not containing '*2.6.20*' inside the package name/version
can be used without any further changes. Only kernel modules build
against the official 2.6.20-grml kernel can't be used any further.

regards,
-mika-
-- 
 http://grml.org/            # Linux for texttool-users and sysadmins
 http://wiki.grml.org/       # share your knowledge
 http://grml.supersized.org/ # the grml development weblog
 #grml @ irc.freenode.org    # meet us on irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mur.at/pipermail/grml/attachments/20070526/512e0d06/attachment-0002.pgp