Proposal to add additional annotated tags

Proposal to add additional annotated tags

[Florian Weimer]

I would like to add the following annotated tags:

00cdcf5a4110f7ac68651f5662693c82f7bffaca   glibc-2.26.9000
58557c229319a3b8d2eefdb62e7df95089eabe37   glibc-2.25.9000
e720d3d9fea2058adb3de2905f1a399ad3e812ff   glibc-2.24.9000
c6f391dbf9b3b33e5bc0599dd96c40a0eff2f02b   glibc-2.23.9000
1b15ff4810748abee11b949e6faa115f3f2d20f4   glibc-2.22.9000
d5a8b70560cf758218c13bef6f1dd93ce216424f   glibc-2.21.9000
21c83793a223666b8cfe438d81615941896b355c   glibc-2.20.9000
d5b396c1c89ed3026fc89bfcdd72b14d59972e45   glibc-2.19.9000
6c1fd795711bb510cffaab5ad2ab2739bb8db210   glibc-2.18.9000
2c8bfe7d6f22c4a599894846bf1715d93b295f53   glibc-2.17.9000
e64ac02c24b43659048622714afdc92fedf561fa   glibc-2.16.9000

The proposed tag message is “glibc 2.17 development” for the last one,
and counting upwards from that.

The reason is that this makes “git describe” unique because its output
no longer collides with the release branches.  The “.9000” suffix is
completely arbitrary, but it suggests that these numbers are not
comparable with the numbers on release branches.  The tags sort before
the following release (and its tag) according to most version number
comparison algorithms.

Comments?

(I will investigate how to change the existing update hook on
sourceware.org how to reject commits with multiple parents on the
master branches, so the numbers will certainly be unique in the
future.)

Re: Proposal to add additional annotated tags

[Siddhesh Poyarekar]

On Saturday 14 October 2017 02:51 AM, Florian Weimer wrote:
> I would like to add the following annotated tags:
> 
> 00cdcf5a4110f7ac68651f5662693c82f7bffaca   glibc-2.26.9000
> 58557c229319a3b8d2eefdb62e7df95089eabe37   glibc-2.25.9000
> e720d3d9fea2058adb3de2905f1a399ad3e812ff   glibc-2.24.9000
> c6f391dbf9b3b33e5bc0599dd96c40a0eff2f02b   glibc-2.23.9000
> 1b15ff4810748abee11b949e6faa115f3f2d20f4   glibc-2.22.9000
> d5a8b70560cf758218c13bef6f1dd93ce216424f   glibc-2.21.9000
> 21c83793a223666b8cfe438d81615941896b355c   glibc-2.20.9000
> d5b396c1c89ed3026fc89bfcdd72b14d59972e45   glibc-2.19.9000
> 6c1fd795711bb510cffaab5ad2ab2739bb8db210   glibc-2.18.9000
> 2c8bfe7d6f22c4a599894846bf1715d93b295f53   glibc-2.17.9000
> e64ac02c24b43659048622714afdc92fedf561fa   glibc-2.16.9000
> 
> The proposed tag message is “glibc 2.17 development” for the last one,
> and counting upwards from that.
> 
> The reason is that this makes “git describe” unique because its output
> no longer collides with the release branches.  The “.9000” suffix is
> completely arbitrary, but it suggests that these numbers are not
> comparable with the numbers on release branches.  The tags sort before
> the following release (and its tag) according to most version number
> comparison algorithms.
> 
> Comments?

I think this is a good thing to add to the release checklist for the
future as well.  Given that there are some who would prefer the option
of a point release, the path of least resistance would probably to let
both coexist for now.

siddhesh

Re: Proposal to add additional annotated tags

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On Fri, Oct 13, 2017 at 11:21:34PM +0200, Florian Weimer wrote:
> I would like to add the following annotated tags:
> 
> 00cdcf5a4110f7ac68651f5662693c82f7bffaca   glibc-2.26.9000
> 58557c229319a3b8d2eefdb62e7df95089eabe37   glibc-2.25.9000
> e720d3d9fea2058adb3de2905f1a399ad3e812ff   glibc-2.24.9000
> c6f391dbf9b3b33e5bc0599dd96c40a0eff2f02b   glibc-2.23.9000
> 1b15ff4810748abee11b949e6faa115f3f2d20f4   glibc-2.22.9000
> d5a8b70560cf758218c13bef6f1dd93ce216424f   glibc-2.21.9000
> 21c83793a223666b8cfe438d81615941896b355c   glibc-2.20.9000
> d5b396c1c89ed3026fc89bfcdd72b14d59972e45   glibc-2.19.9000
> 6c1fd795711bb510cffaab5ad2ab2739bb8db210   glibc-2.18.9000
> 2c8bfe7d6f22c4a599894846bf1715d93b295f53   glibc-2.17.9000
> e64ac02c24b43659048622714afdc92fedf561fa   glibc-2.16.9000

As the last commit is from the ports tree that has no common history
with glibc-2.16.0, I suggest tagging
e64ac02c24b43659048622714afdc92fedf561fa as glibc-2.16-ports-before-merge,
and the subsequent merge commit e84eabb3871c9b39e59323bf3f6b98c2ca9d1cd0
as glibc-2.16.9000.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Proposal to add additional annotated tags

[Carlos O'Donell]

On 10/13/2017 02:21 PM, Florian Weimer wrote:
> I would like to add the following annotated tags:
> 
> 00cdcf5a4110f7ac68651f5662693c82f7bffaca   glibc-2.26.9000
> 58557c229319a3b8d2eefdb62e7df95089eabe37   glibc-2.25.9000
> e720d3d9fea2058adb3de2905f1a399ad3e812ff   glibc-2.24.9000
> c6f391dbf9b3b33e5bc0599dd96c40a0eff2f02b   glibc-2.23.9000
> 1b15ff4810748abee11b949e6faa115f3f2d20f4   glibc-2.22.9000
> d5a8b70560cf758218c13bef6f1dd93ce216424f   glibc-2.21.9000
> 21c83793a223666b8cfe438d81615941896b355c   glibc-2.20.9000
> d5b396c1c89ed3026fc89bfcdd72b14d59972e45   glibc-2.19.9000
> 6c1fd795711bb510cffaab5ad2ab2739bb8db210   glibc-2.18.9000
> 2c8bfe7d6f22c4a599894846bf1715d93b295f53   glibc-2.17.9000
> e64ac02c24b43659048622714afdc92fedf561fa   glibc-2.16.9000
> 
> The proposed tag message is “glibc 2.17 development” for the last one,
> and counting upwards from that.
> 
> The reason is that this makes “git describe” unique because its output
> no longer collides with the release branches.  The “.9000” suffix is
> completely arbitrary, but it suggests that these numbers are not
> comparable with the numbers on release branches.  The tags sort before
> the following release (and its tag) according to most version number
> comparison algorithms.
> 
> Comments?
> 
> (I will investigate how to change the existing update hook on
> sourceware.org how to reject commits with multiple parents on the
> master branches, so the numbers will certainly be unique in the
> future.)

This looks good to me. When I was developing the Release process
I struggled a bit to define what this would look like, and never
came back to adding more tags for the development process. Your
idea is in line with the whole process though, so I'm happy to
see this go forward. As Siddhesh comments, please add a step in
the release process to make sure these go in.

-- 
Cheers,
Carlos.

Re: Proposal to add additional annotated tags

[Florian Weimer]

On 10/16/2017 08:21 PM, Dmitry V. Levin wrote:
> On Fri, Oct 13, 2017 at 11:21:34PM +0200, Florian Weimer wrote:
>> I would like to add the following annotated tags:
>>
>> 00cdcf5a4110f7ac68651f5662693c82f7bffaca   glibc-2.26.9000
>> 58557c229319a3b8d2eefdb62e7df95089eabe37   glibc-2.25.9000
>> e720d3d9fea2058adb3de2905f1a399ad3e812ff   glibc-2.24.9000
>> c6f391dbf9b3b33e5bc0599dd96c40a0eff2f02b   glibc-2.23.9000
>> 1b15ff4810748abee11b949e6faa115f3f2d20f4   glibc-2.22.9000
>> d5a8b70560cf758218c13bef6f1dd93ce216424f   glibc-2.21.9000
>> 21c83793a223666b8cfe438d81615941896b355c   glibc-2.20.9000
>> d5b396c1c89ed3026fc89bfcdd72b14d59972e45   glibc-2.19.9000
>> 6c1fd795711bb510cffaab5ad2ab2739bb8db210   glibc-2.18.9000
>> 2c8bfe7d6f22c4a599894846bf1715d93b295f53   glibc-2.17.9000
>> e64ac02c24b43659048622714afdc92fedf561fa   glibc-2.16.9000
> 
> As the last commit is from the ports tree that has no common history
> with glibc-2.16.0, I suggest tagging
> e64ac02c24b43659048622714afdc92fedf561fa as glibc-2.16-ports-before-merge,
> and the subsequent merge commit e84eabb3871c9b39e59323bf3f6b98c2ca9d1cd0
> as glibc-2.16.9000.

Okay, that is certainly a better solution.

Should I use .90 in the tags and not .9000?  I'm asking because

-#define RELEASE "stable"
-#define VERSION "2.26"
+#define RELEASE "development"
+#define VERSION "2.26.90"

we use .90 versions during development.  (I mistakenly assumed that this 
was something Fedora-specific.)  I switched to .9000 to avoid collisions 
with point-release tarballs from a long-lived release branch branch.

Thanks,
Florian

Re: Proposal to add additional annotated tags

[Carlos O'Donell]

On 10/16/2017 12:10 PM, Florian Weimer wrote:
> On 10/16/2017 08:21 PM, Dmitry V. Levin wrote:
>> On Fri, Oct 13, 2017 at 11:21:34PM +0200, Florian Weimer wrote:
>>> I would like to add the following annotated tags:
>>>
>>> 00cdcf5a4110f7ac68651f5662693c82f7bffaca   glibc-2.26.9000
>>> 58557c229319a3b8d2eefdb62e7df95089eabe37   glibc-2.25.9000
>>> e720d3d9fea2058adb3de2905f1a399ad3e812ff   glibc-2.24.9000
>>> c6f391dbf9b3b33e5bc0599dd96c40a0eff2f02b   glibc-2.23.9000
>>> 1b15ff4810748abee11b949e6faa115f3f2d20f4   glibc-2.22.9000
>>> d5a8b70560cf758218c13bef6f1dd93ce216424f   glibc-2.21.9000
>>> 21c83793a223666b8cfe438d81615941896b355c   glibc-2.20.9000
>>> d5b396c1c89ed3026fc89bfcdd72b14d59972e45   glibc-2.19.9000
>>> 6c1fd795711bb510cffaab5ad2ab2739bb8db210   glibc-2.18.9000
>>> 2c8bfe7d6f22c4a599894846bf1715d93b295f53   glibc-2.17.9000
>>> e64ac02c24b43659048622714afdc92fedf561fa   glibc-2.16.9000
>>
>> As the last commit is from the ports tree that has no common history
>> with glibc-2.16.0, I suggest tagging
>> e64ac02c24b43659048622714afdc92fedf561fa as glibc-2.16-ports-before-merge,
>> and the subsequent merge commit e84eabb3871c9b39e59323bf3f6b98c2ca9d1cd0
>> as glibc-2.16.9000.
> 
> Okay, that is certainly a better solution.
> 
> Should I use .90 in the tags and not .9000?  I'm asking because
> 
> -#define RELEASE "stable"
> -#define VERSION "2.26"
> +#define RELEASE "development"
> +#define VERSION "2.26.90"
> 
> we use .90 versions during development.  (I mistakenly assumed that
> this was something Fedora-specific.)  I switched to .9000 to avoid
> collisions with point-release tarballs from a long-lived release
> branch branch.

Why don't we change VERSION to 2.26.9000 to make the tags match?

The choice of .90 was always arbitrary.

I see nothing but benefit in using a larger development revision
number.

-- 
Cheers,
Carlos.

Re: Proposal to add additional annotated tags

[Florian Weimer]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On 10/16/2017 09:15 PM, Carlos O'Donell wrote:

>> Should I use .90 in the tags and not .9000?  I'm asking because
>>
>> -#define RELEASE "stable"
>> -#define VERSION "2.26"
>> +#define RELEASE "development"
>> +#define VERSION "2.26.90"
>>
>> we use .90 versions during development.  (I mistakenly assumed that
>> this was something Fedora-specific.)  I switched to .9000 to avoid
>> collisions with point-release tarballs from a long-lived release
>> branch branch.
> 
> Why don't we change VERSION to 2.26.9000 to make the tags match?
> 
> The choice of .90 was always arbitrary.
> 
> I see nothing but benefit in using a larger development revision
> number.

Testing showed no problems caused by .9000.  I'm going to install the 
attached patch.

I will use .90 tags for the older development branches, and the .9000 
tag for the new branch only.

Thanks,
Florian

[-- Attachment #2: version.patch --]
[-- Type: text/x-patch, Size: 405 bytes --]


2017-10-16  Florian Weimer  <fweimer@redhat.com>

	* version.h (VERSION): Switch to ".9000" as the development
	version suffix.

diff --git a/version.h b/version.h
index b6a0412847..788d0c3509 100644
--- a/version.h
+++ b/version.h
@@ -1,4 +1,4 @@
 /* This file just defines the current version number of libc.  */
 
 #define RELEASE "development"
-#define VERSION "2.26.90"
+#define VERSION "2.26.9000"

Re: Proposal to add additional annotated tags

[Carlos O'Donell]

On 10/16/2017 12:41 PM, Florian Weimer wrote:
> 
>>> Should I use .90 in the tags and not .9000?  I'm asking because
>>>
>>> -#define RELEASE "stable"
>>> -#define VERSION "2.26"
>>> +#define RELEASE "development"
>>> +#define VERSION "2.26.90"
>>>
>>> we use .90 versions during development.  (I mistakenly assumed that
>>> this was something Fedora-specific.)  I switched to .9000 to avoid
>>> collisions with point-release tarballs from a long-lived release
>>> branch branch.
>>
>> Why don't we change VERSION to 2.26.9000 to make the tags match?
>>
>> The choice of .90 was always arbitrary.
>>
>> I see nothing but benefit in using a larger development revision
>> number.
> 
> Testing showed no problems caused by .9000.  I'm going to install the attached patch.
> 
> I will use .90 tags for the older development branches, and the .9000 tag for the new branch only.
 
This looks good to me. Please update the Release wiki document
to instruct the release manager to use 9000.
 
> 2017-10-16  Florian Weimer  <fweimer@redhat.com>
> 
> 	* version.h (VERSION): Switch to ".9000" as the development
> 	version suffix.
> 
> diff --git a/version.h b/version.h
> index b6a0412847..788d0c3509 100644
> --- a/version.h
> +++ b/version.h
> @@ -1,4 +1,4 @@
>  /* This file just defines the current version number of libc.  */
>  
>  #define RELEASE "development"
> -#define VERSION "2.26.90"
> +#define VERSION "2.26.9000"


-- 
Cheers,
Carlos.