what to call it after 2.6.23 but before 2.6.24-rc1?

what to call it after 2.6.23 but before 2.6.24-rc1?

[Erez Zadok]

Linus, is there a preferred name to refer to the kernel version in your tree
after 2.6.23 is out (and the official 2.6.23.y git was created) but before
you release 2.6.24-rc1?  I've seen online references to it as "2.6.24",
"2.6.24++", "2.6.24-rc0", etc.  Since your top-level Makefile still says
"2.6.23", it is sometimes a bit confusing when one is testing code against
your tree as well as the previously released stable kernel.  I usually will
stick a localversion file in my cloned copy of your tree, saying
"2.6.24-pre-rc" or so.  Perhaps you can come up with a definitive name for
this "limbo" state and put it in your Makefile?

Anyway, 'tis just a minor quibble (which I hope won't start yet another
major "naming" flame war :-0

Thanks,
Erez.

Re: what to call it after 2.6.23 but before 2.6.24-rc1?

[Linus Torvalds]

On Sat, 20 Oct 2007, Erez Zadok wrote:
>
> Linus, is there a preferred name to refer to the kernel version in your tree
> after 2.6.23 is out (and the official 2.6.23.y git was created) but before
> you release 2.6.24-rc1?

Well, since you can only get one of those kernels in two ways, there's a 
very unambiguous naming policy.

 - if you got one of the nightly snapshots, name it by the snapshot name 
   (I still call them "nightly snapshots", but they do in fact happen 
   twice a day if there have been changes, so that's not technically 
   correct)

   So the last snapshot would be linux-2.6.23-git15

   This is an exact name, because you can go to kernel.org and look up the 
   exact commit ID that was used to generate it (there's an "ID" file 
   associated with each snapshot there).

   For bonus points, if you report a bug against such a snapshot, look up 
   the ID yourself, so that others don't have to do that..

 - if you are a git user, and got it that way, just use the git name, and 
   use "git describe" to get it.

   So my current head is called "v2.6.23-6562-g8add244" which tells you 
   three things:
     (a) it's based on 2.6.23
     (b) there's been 6562 commits since 2.6.23
     (c) the top-of-tree abbreviated commit is "8add244".

> I've seen online references to it as "2.6.24", "2.6.24++", "2.6.24-rc0", 
> etc.

Yeah, please don't use those names. They don't actually tell anything 
about where in the cycle it is, and as you can see above, there's been 
6500+ commits since 2.6.23, so saying "2.6.23-rc0" or similar really isn't 
very helpful if anybody actually cares about just where in the release 
cycle you are.

			Linus

Re: what to call it after 2.6.23 but before 2.6.24-rc1?

[Erez Zadok]

In message <alpine.LFD.0.999.0710201517530.10525@woody.linux-foundation.org>, Linus Torvalds writes:

> On Sat, 20 Oct 2007, Erez Zadok wrote:
[...]

>  - if you are a git user, and got it that way, just use the git name, and 
>    use "git describe" to get it.
> 
>    So my current head is called "v2.6.23-6562-g8add244" which tells you 
>    three things:
>      (a) it's based on 2.6.23
>      (b) there's been 6562 commits since 2.6.23
>      (c) the top-of-tree abbreviated commit is "8add244".

Bingo.  git-describe is what I was looking for.  It's more accurate to use
as a reference even after rcN come out.  My current cloned tree of yours
sez:

	v2.6.23-6562-g8add244

One more small git question: I keep a separate tree for unionfs, which I
rebase often based on your tree.  But my tree sez:

$ git-describe
v2.6.21-rc1-22880-g3a1848d

"v2.6.21-rc1"?  What am I missing (some tags I forgot to pull?)  Why isn't
git-describe saying that I'm based on your latest tree?

Thanks,
Erez.

Re: what to call it after 2.6.23 but before 2.6.24-rc1?

[Linus Torvalds]

On Sat, 20 Oct 2007, Erez Zadok wrote:
>
> One more small git question: I keep a separate tree for unionfs, which I
> rebase often based on your tree.  But my tree sez:
> 
> $ git-describe
> v2.6.21-rc1-22880-g3a1848d
> 
> "v2.6.21-rc1"?  What am I missing (some tags I forgot to pull?)  Why isn't
> git-describe saying that I'm based on your latest tree?

Sounds like you don't have the tags. Do

	git fetch --tags <repo> 

to get them.

There can be several reasons why you don't have the tags, but the two most 
likely ones are:

 - really old versions of git didn't fetch tags by default.

   (not very likely, because it's *really* old, but still, worth 
   mentioning as one possible reason)

 - if you don't fetch into a "tracking" branch, but instead do an 
   "anonymous" fetch into FETCH_HEAD that is then directly merged (or you 
   just rebase your work on top of it), git won't fetch tags, since it 
   assumes that you only want to fetch the one head you mentioned.

but regardless, you can always fetch the tags manually.

		Linus