This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Glibc stable release process (Glibc 2.26.1)
Florian, All,
On 2017-10-16 18:52 +0200, Florian Weimer spake thusly:
> On 10/16/2017 05:55 PM, Yann E. MORIN wrote:
> >Hello All! :-)
> >
> >On 2017-10-16 15:20 +0200, Florian Weimer spake thusly:
> >>On 10/16/2017 02:48 PM, Siddhesh Poyarekar wrote:
> >>>On Friday 13 October 2017 01:29 AM, Florian Weimer wrote:
> >>>>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).
> >>>
> >>>This is a good idea in general and a trivial point to add to the release
> >>>process. Do you intend to propose this as a full replacement for point
> >>>releases (i.e. never do it) or just an added convenience for those who
> >>>don't care for point releases or a fallback for when the release manager
> >>>(or one of the package signers, i.e. Carlos, Joseph, me, etc.) does not
> >>>want to spend time on a point release?
> >>
> >>I think it's a sufficient replacement for point releases, but I suppose
> >>others will disagree.
> >
> >Well, I won't re-hash the explanations I expressed, but I'll just state
> >that a point-release would be better, IMHO. It is not necessary to put
> >out tarballs, though; a tag would be enough.
>
> Why do you think a tag would be superior to the output from “git describe”?
> Because we can change it subsequently to point something else?
TL;DR:
The difference is where the identification comes from:
- a tag is generated is one location: upstream;
- git-describe is local and arbitrary to each downstream.
Full text:
A tag is semantically immutable [0]; as soon as it exists, a tag will
always exist, and always point to the same commit. The name of the tag
bears sematic as well; it is a human-readable sequencing. But most
important of all, a tag is generated by _upstream_.
git-describe on the other hand is run by a _downstream_ to generate a
seemingly human-readable version number. The problem is not that the
output of git-describe is not immutable; the problem is to choose the
actual commit to run it on.
The problem is not about representation of the version string. It is
actually choosing what commit to use. As a downstream, we don't have
many options when we need to choose a commit on the maintenance branch
[1], i.e. either one of:
- use the HEAD of the branch
- use any one commit between the tag and the HEAD
Let's say we choose HEAD now, and then tomorrow you push 5 new commits.
Then the HEAD we choose today will tomorrow be seen just as randomly
chosen as any other commit. It will tomorrow not mean much more than
if we had clicked on the "I feel lucky" button then.
As a consequence, it is very difficult to express what glibc version is
running on a system, because it would only ever report '2.26' (or am I
mislead?), so it will be difficult to state "2.26 works in that setup"
when someone else states "2.26 does not work in that setup", just
because it is in fact not the same '2.26', being cut off of different
commits. A tag would actually have glibc version be '2.26.1' (or
whatever) so it would be easier to compare.
Thanks! ;-)
Regards,
Yann E. MORIN.
[0] yes, technically, you can move/remove a tag. That's just bad; don't
do it! ;-)
[1] I will suppose that all commits that go to the maintenance branch
are all fixing stuff (bug fix, security fix) and never a new feature
or an API/ABI breakage or whatever. Just actual fixes. As such, they
are all equal in importance: a fix is a fix; by the mere existence
of it, it is required.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'