Kernel naming convention in the merge phase
RFC 1/1 Kernel naming convention in the merge phase
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:
------
Makefile +0 -0
@@ -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
Quoted 25 lines · 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
Makefileshould be changed at the beginning of this phase to identify the ongoing work for the 2.6.26:------
Makefile +0
-0@@ -1,8 +1,8 @@VERSION = 2
PATCHLEVEL = 6Makefile +3
-3-SUBLEVEL = 25 -EXTRAVERSION = -NAME = Funky Weasel is Jiggy wit it +SUBLEVEL = 26 +EXTRAVERSION = -merge +NAME = unnamed
Quoted 6 lines
# *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/modulesand 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
Quoted 9 lines · H. Peter Anvin
Quoted 8 lines · Oliver Hartkopp
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
Makefileshould be changed at the beginning of this phase to identify the ongoing work for the 2.6.26:
Quoted 8 lines
Quoted 4 lines
(..)
Introducing the new '-merge' version _that_ early helps to avoid the version confusion in
/lib/modulesand 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
Quoted 3 lines · Oliver Hartkopp
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.
Quoted 1 line
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
Quoted 6 lines · H. Peter Anvin
Most of the robots don't have access to git.
Quoted 2 lines
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
Signature · 8 lines
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.
Quoted 6 lines · Romano Giannetti
Quoted 3 lines · H. Peter Anvin
Most of the robots don't have access to git.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 3 lines · Oliver Hartkopp
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
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines · Oliver Hartkopp
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.
Quoted 12 lines · Oliver Hartkopp
Quoted 6 lines · H. Peter Anvin
Quoted 3 lines · Oliver Hartkopp
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
Quoted 11 lines · H. Peter Anvin
Quoted 10 lines · Oliver Hartkopp
Quoted 8 lines · H. Peter Anvin
Quoted 5 lines · Oliver Hartkopp
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.
Quoted 8 lines
Quoted 5 lines
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
Quoted 4 lines · Oliver Hartkopp
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
Quoted 3 lines · Oliver Hartkopp
Quoted 2 lines · Romano Giannetti
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.
Quoted 1 line
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.
Signature · 3 lines
Stefan Richter -=====-==--- -=-= -==-- http://arcgraph.de/sr/
Quoted 42 lines · H. Peter Anvin
Quoted 29 lines · 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
Makefileshould be changed at the beginning of this phase to identify the ongoing work for the 2.6.26:------
Makefile +0
-0@@ -1,8 +1,8 @@VERSION = 2
PATCHLEVEL = 6Makefile +3
-3-SUBLEVEL = 25 -EXTRAVERSION = -NAME = Funky Weasel is Jiggy wit it +SUBLEVEL = 26 +EXTRAVERSION = -merge +NAME = unnamedQuoted 9 lines
# *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/modulesand also allows people to work with kernel version depended stuff in a very early phase.And it'll break all the robotic stuff again.
Quoted 2 lines
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
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 9 lines · Pavel Machek
Quoted 2 lines
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