Kernel versioning [was Re: Kernel package and modules]

[Mike (mwester)]

Andy Green wrote:
> 
> You might noticed I called it "module versioning" :-)  But we have
> another way to come at by EXTRAVERSION with the git hash, that solves
> another issue too.

Let's re-open the discussion on this, I think there's a better solution.

I remain opposed to the use of the git hash for EXTRAVERSION; that's
unnecessary and pushes the problem off to others.  (The git hash should
be, as I proposed (and implemented on my kernels), in the
"user at buildhost" string where it serves to identity, not do
configuration management.)

The use of EXTRAVERSION should be a simple sequential integer (perhaps
combined with some other strings if people desire), bumped up by human
beings whenever "stable" changes.  It should also be optionally bumped
up on other branches whenever the developers feel uncomfortable about
leaving it unchanged (we all know that there are numerous minor tweaks
that we make that do not impact modules or the ABI for modules, or even
the data structures they use).

It makes little difference to end users, it makes a world of difference
to developers (ok, maybe not all of them, but certainly it does for me).
 Right now I can inspect a patch that gets added to the "andy" branch,
for example, add it to my tree, build, flash a kernel, and see how it
works.  That's good.

But I'm lazy.  And that means that if I *also* had to package up a
tarball of all the modules, copy them up to the rootfs, make sure I have
space, untar them, remember to delete them when done, just so I could
boot that kernel to do that test, well, it's less likely that I'm going
to find time to do that.

And the argument that I could go check the git hash thingy in the
existing rootfs, edit the kernel Makefile to match, and build that is
also just way too much work to make it likely that I or many others
would actually bother.

The git hash, as proposed, is a horrible little thing that should be
there, but not in EXTRAVERSION.  The EXTRAVERSION should be changed as I
describe above, by humans, because we need for as many people as
possible to be able to test kernels and kernel-patches, and with the
current change rate the very last thing we should be considering is
making it harder for people to help out in the testing effort.

JMO, as always.

Mike (mwester)