Re: Glibc stable release process (Glibc 2.26.1)

[Florian Weimer <fweimer at redhat dot com>]

On 10/12/2017 09:29 PM, Dmitry V. Levin wrote:
> On Fri, Sep 29, 2017 at 05:26:23PM -0700, Paul Eggert wrote:
> > Romain Naour wrote:
> > > Maybe a middle ground is that a tag is pushed to the repository, just to
> > > identify a specific sha1 as "this is 2.26.1". This is relatively lightweight (a
> > > signed tag) and gives downstream users that need it a clear identification of a
> > > blessed version.
> > That "blessing" would be problematic. How can we be expected to "bless" any
> > particular commit unless we've checked it? And that checking will take some
> > work, work that will slow us down on other things.
> >
> > Instead of blessing, how about using the output of something like the following
> > shell command to generate the version number?
> >
> > git describe --match 'glibc-*' --abbrev=7 --dirty
> >
> > This will generate a string that identifies the commit but is shorter and easier
> > to read than an SHA hash, and so is more likely to give users that warm and
> > fuzzy feeling. On my glibc repository right now, for example, it generates:
> >
> > glibc-2.26-415-g4d3693e
> >
> > which means there have been 415 commits since 2.26, and the latest commit can be
> > abbreviated 4d3693e. A similar (but shorter) version-numbering scheme is used by
> > GNU Coreutils and other GNU packages when between releases, and Gnulib has a
> > script build-aux/git-version-gen that can generate it.
>
> We (ALT) adopted this scheme for most of the packages that are built from
> git snapshots, and I think this is the way to go.  git is available for
> more than 12 years, why some distro builders need an officially released
> tarball made from release/2.26/master branch that would be no better than
> current glibc-2.26-58-gf725563 (aka 2.26.0.58.f725563 in git-version-gen's
> notation) is beyond my understanding.

Right, I share your puzzlement.

The only thing I think we could improve is that we should tag the first 
tag after a release branches with something like glibc-X.Y.9000, so that 
the git describe output is actually unique between the release branch 
and the next development branch (also, we should have update hooks which 
reject commits with multiple parents on the master branches).

I'd propose to add the following 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
c758a6861537815c759cba2018a3b1abb1943842   glibc-2.17.9000
75f0d3040a2c2de8842bfa7a09e11da1a73e17d0   glibc-2.16.9000

The latter has also a glibc-2.16.0 tag, but I think that's misleading. 
The .9000 part (or any large number, really) confers that it's an 
artificial number, and it will sort correctly in most version number 
orderings.

Would these new tags break something for you?  They won't change 
anything on the release branches, only on the master branch.

If you don't see a problem with that, I'm going to suggest this on a 
separate thread (it's too buried here to receive proper attention).

Thanks,
Florian