Re: Proposal to add additional annotated tags

[Carlos O'Donell <carlos at redhat dot com>]

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.