Glibc stable release process (Glibc 2.26.1)

[Dmitry V. Levin]

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.

It would be a different story if somebody volunteered to do a proper
release testing of point releases similar to what's currently done
or releases, see e.g. https://sourceware.org/glibc/wiki/Release/2.26

Are those projects that want point release tarballs are ready to do
a proper pre-release testing?  If yes, then it makes sense to do
point releases.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20171012/daa88c62/attachment.sig>