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 --
And it'll break all the robotic stuff again. Foo-gitX has always been a development snapshot which *follows* Foo. -hpa --
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 --
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
--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 --
Tough. It's a naming convention quite old (we had -bk before -git, too.) -hpa --
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. --
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 --
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/ --
Either way it'll take a bunch of work. -hpa --
Can you give any details? Why does tagging a -rc0 create any effort for anyone - except half a minute for Linus? Oliver. --
Because it breaks all the robots which rely on the kernel naming scheme. Again. You already asked. -hpa --
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 --
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 --
| Artem Bityutskiy | [PATCH 00/22 take 3] UBI: Unsorted Block Images |
| Greg Kroah-Hartman | [PATCH 022/196] adb: Convert from class_device to device |
| Parag Warudkar | BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0] |
| Ingo Molnar | Re: pthread_create() slow for many threads; also time to revisit 64b context switc... |
git: | |
| Bill Lear | Meaning of "fatal: protocol error: bad line length character"? |
| Ludovic | `git-send-email' doesn't specify `Content-Type' |
| Miles Bader | multiple-commit cherry-pick? |
| JD Guzman | C# Git Implementation |
| Martin Schröder | Re: Real men don't attack straw men |
| Jacob Meuser | Re: esd + mpd |
| Daniel Ouellet | identifying sparse files and get ride of them trick available? |
| Todd Pytel | IDE or SCSI virtual disks for VMWare image? |
| David Miller | Re: kernel oops when system under network stress |
| Denys Fedoryshchenko | thousands of classes, e1000 TX unit hang |
| Eric Dumazet | [PATCH 6/6] fs: Introduce kern_mount_special() to mount special vfs |
| Леонид Юрьев | [r8169] patch for RTL8102 (5 new MAC/PHY) |
