Kernel versioning [was Re: Kernel package and modules]
k.kooi at student.utwente.nl
Tue Aug 5 16:21:25 CEST 2008
Op 5 aug 2008, om 15:57 heeft Mike (mwester) het volgende geschreven:
> 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
> 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
> 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
> the data structures they use).
> It makes little difference to end users, it makes a world of
> to developers (ok, maybe not all of them, but certainly it does for
> 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
> 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
> 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.
EXTRAVERSION implies it is a version, and versions are sortable. Git
revisions aren't sortabled and hence unsuited to be using in versions.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.openmoko.org/pipermail/devel/attachments/20080805/3df22e61/attachment.pgp
More information about the devel