[RFC] Kernel naming convention in the merge phase

[RFC] Kernel naming convention in the merge phase

[Oliver Hartkopp]

Hi all,

i wonder about the Kernel naming convention in the merge phase before
the -rc1 is officially tagged by Linus.

Won't it be more precisely to name the current snapshot
2.6.26-merge-git16 instead of 2.6.25-git16?

It is not that i would suggest to have a new git tag in this merge phase 
but only the Makefile should be changed at the beginning of this phase 
to identify the ongoing work for the 2.6.26:

------
diff --git a/Makefile b/Makefile
index d3634cd..b8c85a4 100644
--- a/Makefile
+++ b/Makefile
@@ -1,8 +1,8 @@
VERSION = 2
PATCHLEVEL = 6
-SUBLEVEL = 25
-EXTRAVERSION =
-NAME = Funky Weasel is Jiggy wit it
+SUBLEVEL = 26
+EXTRAVERSION = -merge
+NAME = unnamed

# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
------

Introducing the new '-merge' version _that_ early helps to avoid the 
version confusion in /lib/modules and also allows people to work with 
kernel version depended stuff in a very early phase.

Regards,
Oliver

Re: [RFC] Kernel naming convention in the merge phase

[H. Peter Anvin]

Oliver Hartkopp wrote:
> Hi all,
> 
> i wonder about the Kernel naming convention in the merge phase before
> the -rc1 is officially tagged by Linus.
> 
> Won't it be more precisely to name the current snapshot
> 2.6.26-merge-git16 instead of 2.6.25-git16?
> 
> It is not that i would suggest to have a new git tag in this merge phase 
> but only the Makefile should be changed at the beginning of this phase 
> to identify the ongoing work for the 2.6.26:
> 
> ------
> diff --git a/Makefile b/Makefile
> index d3634cd..b8c85a4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,8 +1,8 @@
> VERSION = 2
> PATCHLEVEL = 6
> -SUBLEVEL = 25
> -EXTRAVERSION =
> -NAME = Funky Weasel is Jiggy wit it
> +SUBLEVEL = 26
> +EXTRAVERSION = -merge
> +NAME = unnamed
> 
> # *DOCUMENTATION*
> # To see a list of typical targets execute "make help"
> ------
> 
> Introducing the new '-merge' version _that_ early helps to avoid the 
> version confusion in /lib/modules and also allows people to work with 
> kernel version depended stuff in a very early phase.
> 

And it'll break all the robotic stuff again.

Foo-gitX has always been a development snapshot which *follows* Foo.

	-hpa

Re: [RFC] Kernel naming convention in the merge phase

[Oliver Hartkopp]

H. Peter Anvin wrote:
> Oliver Hartkopp wrote:
>> i wonder about the Kernel naming convention in the merge phase before
>> the -rc1 is officially tagged by Linus.
>>
>> Won't it be more precisely to name the current snapshot
>> 2.6.26-merge-git16 instead of 2.6.25-git16?
>>
>> It is not that i would suggest to have a new git tag in this merge 
>> phase but only the Makefile should be changed at the beginning of 
>> this phase to identify the ongoing work for the 2.6.26:
>>
>> (..)
>>
>> Introducing the new '-merge' version _that_ early helps to avoid the 
>> version confusion in /lib/modules and also allows people to work with 
>> kernel version depended stuff in a very early phase.
>>
>
> And it'll break all the robotic stuff again.
>
> Foo-gitX has always been a development snapshot which *follows* Foo.

Hm - if it breaks the robotic stuff, there could be a real 
"v2.6.26-merge" git tag which shouldn't break like "v2.6.26-rc1".

It could look like this:

- tag v2.6.25
- drink a beer
- tag v2.6.26-merge
- pull the new stuff from subsystem maintainers
- tag v2.6.26-rc1
- ...

For me a 2.6.25-gitX looks like a snapshot that leads to a 2.6.25.1 and 
_not_ to a 2.6.26-rc1. The current 2.6.25-git16 is moch more a 2.6.26 
than a 2.6.25. So v2.6.26-merge-git16 makes it much clearer what's going 
on here.

To tag Linus' tree with v2.6.26-merge before pulling all the new 2.6.26 
stuff seems therefore reasonable to me. But maybe i don't have all the 
dependencies on my radar.

Regards,
Oliver

Re: [RFC] Kernel naming convention in the merge phase

[H. Peter Anvin]

Oliver Hartkopp wrote:
> 
> Hm - if it breaks the robotic stuff, there could be a real 
> "v2.6.26-merge" git tag which shouldn't break like "v2.6.26-rc1".
> 

Most of the robots don't have access to git.

> For me a 2.6.25-gitX looks like a snapshot that leads to a 2.6.25.1 and 
> _not_ to a 2.6.26-rc1.

Tough.  It's a naming convention quite old (we had -bk before -git, too.)

	-hpa

Re: [RFC] Kernel naming convention in the merge phase

[Romano Giannetti]

On Thu, 2008-05-01 at 11:06 -0700, H. Peter Anvin wrote:

> Most of the robots don't have access to git.
> 
> > For me a 2.6.25-gitX looks like a snapshot that leads to a 2.6.25.1 and 
> > _not_ to a 2.6.26-rc1.
> 
> Tough.  It's a naming convention quite old (we had -bk before -git, too.)

What about a -rc0 as the first commit after a release? Will help a lot
automatic installing scripts...

Romano 
 
-- 
Sorry for the disclaimer --- ¡I cannot stop it!



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 

Re: [RFC] Kernel naming convention in the merge phase

[Oliver Hartkopp]

Romano Giannetti wrote:
> On Thu, 2008-05-01 at 11:06 -0700, H. Peter Anvin wrote:
>
>   
>> Most of the robots don't have access to git.
>>
>>     
>>> For me a 2.6.25-gitX looks like a snapshot that leads to a 2.6.25.1 and 
>>> _not_ to a 2.6.26-rc1.
>>>       
>> Tough.  It's a naming convention quite old (we had -bk before -git, too.)
>>     
>
> What about a -rc0 as the first commit after a release? Will help a lot
> automatic installing scripts...
>
>   

Yes - this was also my intention. I don't have any preferences if the 
first commit after a release is named -merge or -rc0. But it should 
point out that we're leaving the former stable release.

Regards,
Oliver

Re: [RFC] Kernel naming convention in the merge phase

[H. Peter Anvin]

Oliver Hartkopp wrote:
> 
> Yes - this was also my intention. I don't have any preferences if the 
> first commit after a release is named -merge or -rc0. But it should 
> point out that we're leaving the former stable release.
> 

Either way it'll take a bunch of work.

	-hpa

Re: [RFC] Kernel naming convention in the merge phase

[Oliver Hartkopp]

H. Peter Anvin wrote:
> Oliver Hartkopp wrote:
>>
>> Yes - this was also my intention. I don't have any preferences if the 
>> first commit after a release is named -merge or -rc0. But it should 
>> point out that we're leaving the former stable release.
>>
>
> Either way it'll take a bunch of work.

Can you give any details?

Why does tagging a -rc0 create any effort for anyone - except half a 
minute for Linus?

Oliver.

Re: [RFC] Kernel naming convention in the merge phase

[H. Peter Anvin]

Oliver Hartkopp wrote:
> H. Peter Anvin wrote:
>> Oliver Hartkopp wrote:
>>>
>>> Yes - this was also my intention. I don't have any preferences if the 
>>> first commit after a release is named -merge or -rc0. But it should 
>>> point out that we're leaving the former stable release.
>>>
>>
>> Either way it'll take a bunch of work.
> 
> Can you give any details?
> 
> Why does tagging a -rc0 create any effort for anyone - except half a 
> minute for Linus?
> 

Because it breaks all the robots which rely on the kernel naming scheme.

Again.

You already asked.

	-hpa

Re: [RFC] Kernel naming convention in the merge phase

[Oliver Hartkopp]

H. Peter Anvin wrote:
> Oliver Hartkopp wrote:
>> H. Peter Anvin wrote:
>>> Oliver Hartkopp wrote:
>>>>
>>>> Yes - this was also my intention. I don't have any preferences if
>>>> the first commit after a release is named -merge or -rc0. But it
>>>> should point out that we're leaving the former stable release.
>>>>
>>>
>>> Either way it'll take a bunch of work.
>>
>> Can you give any details?
>>
>> Why does tagging a -rc0 create any effort for anyone - except half a
>> minute for Linus?
>>
>
> Because it breaks all the robots which rely on the kernel naming scheme.
>

This is no real detail. How can -rc0 break a naming scheme for a robot,
when -rc1 doesn't?

Btw. you don't seem to have any interest in my suggestion and obviously
Linus, Greg and Andrew also do not have any interest in something like a
-rc0. So i won't create any new noise about that topic from my side.

Thanks anyway,
Oliver

Re: [RFC] Kernel naming convention in the merge phase

[H. Peter Anvin]

Oliver Hartkopp wrote:
> 
> This is no real detail. How can -rc0 break a naming scheme for a robot,
> when -rc1 doesn't?
> 

Because of things like:

- regexp patterns like -(rc|pre)([1-9][0-9]*)
- using zero to mean "no rc/pre"
- assuming 1 is the immediate decendent of the previous one

So on, etc, yadda yadda...

	-hpa

Re: [RFC] Kernel naming convention in the merge phase

[Stefan Richter]

Oliver Hartkopp wrote:
> Romano Giannetti wrote:
>> What about a -rc0 as the first commit after a release? Will help a lot
>> automatic installing scripts...

What is "a lot"?  Maybe the solution is to switch from sh to bash.

> Yes - this was also my intention. I don't have any preferences if the 
> first commit after a release is named -merge or -rc0. But it should 
> point out that we're leaving the former stable release.

2.6.25-git8 says exactly this.  It is a nightly generated patch on top 
of 2.6.25, retrieved from the then current linux-2.6.git.

If you see a -gitX then you know that this is not a release, it is only 
a snapshot.

Your proposed -rc0 on the other hand has, in addition to the drawbacks 
which H. Peter already mentioned, the problem that there would be 
suddenly two release names for one and the same release.  This would 
only increase confusion.

Anyway.  You can always add your own tags in your cloned repository.
-- 
Stefan Richter
-=====-==--- -=-= -==--
http://arcgraph.de/sr/

Re: [RFC] Kernel naming convention in the merge phase

[Pavel Machek]

On Wed 2008-04-30 16:47:24, H. Peter Anvin wrote:
> Oliver Hartkopp wrote:
> >Hi all,
> >
> >i wonder about the Kernel naming convention in the 
> >merge phase before
> >the -rc1 is officially tagged by Linus.
> >
> >Won't it be more precisely to name the current snapshot
> >2.6.26-merge-git16 instead of 2.6.25-git16?
> >
> >It is not that i would suggest to have a new git tag in 
> >this merge phase but only the Makefile should be 
> >changed at the beginning of this phase to identify the 
> >ongoing work for the 2.6.26:
> >
> >------
> >diff --git a/Makefile b/Makefile
> >index d3634cd..b8c85a4 100644
> >--- a/Makefile
> >+++ b/Makefile
> >@@ -1,8 +1,8 @@
> >VERSION = 2
> >PATCHLEVEL = 6
> >-SUBLEVEL = 25
> >-EXTRAVERSION =
> >-NAME = Funky Weasel is Jiggy wit it
> >+SUBLEVEL = 26
> >+EXTRAVERSION = -merge
> >+NAME = unnamed
> >
> ># *DOCUMENTATION*
> ># To see a list of typical targets execute "make help"
> >------
> >
> >Introducing the new '-merge' version _that_ early helps 
> >to avoid the version confusion in /lib/modules and also 
> >allows people to work with kernel version depended 
> >stuff in a very early phase.
> >
> 
> And it'll break all the robotic stuff again.
> 
> Foo-gitX has always been a development snapshot which 
> *follows* Foo.

Well, unfortunately its not there in the makefile, so you can't tell
2.6.25 from 2.6.26-rc0...

Would 'rc0' make robots happy?
							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC] Kernel naming convention in the merge phase

[H. Peter Anvin]

Pavel Machek wrote:
>>
>> Foo-gitX has always been a development snapshot which 
>> *follows* Foo.
> 
> Well, unfortunately its not there in the makefile, so you can't tell
> 2.6.25 from 2.6.26-rc0...
> 
> Would 'rc0' make robots happy?
> 							Pavel
> 

It'll probably make some of them work and break others.  It's pretty 
hard-coded in most of them that the flow is from 2.6.25 -> 
2.6.26-{pre,rc}*; whether or not they permit a zero probably depends on 
if they know what is available or not (ketchup wouldn't be able to, for 
example, but the kernel.org incdiff robot *might* "just work".)

	-hpa