This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Translations gone out for 2.16.
On Tue, 26 Jun 2012, Thomas Schwinge wrote:
> > I have tagged trunk with tag "glibc-2.16-tps" and uploaded a snapshot
> > of the tag for the translation team.
>
> What's the rationale for the tag? I'd prefer to keep the number of
> publically visible tags to a bare minimum, that is, the release tags plus
> perhaps exceptional ones such as the ports merge and similar (but I'm not
> even sure we really need these). In fact, before reading your email I'm
I'm happy with having the tag - it's just putting the snapshot on
ftp.gnu.org that I think is wrong (I think it should be removed from
there, uploaded elsewhere and the TP told about the new location) and the
version number for the snapshot that doesn't conform to the usual
conventions (I don't know whether it will cause problems later, because I
don't know the algorithm by which the TP compares version numbers, but to
a human it's certainly not obvious that 2.16-tps is older than 2.16).
The commit message
<http://sourceware.org/ml/glibc-cvs/2012-q2/msg00852.html> for the tag
says "replaces glibc-2.15" and gives a summary of changes since
glibc-2.15. What controls this "replaces" information? I don't think a
snapshot tag should in any meaningful sense be considered to "replace" a
release tag, and the tag messages for actual release tags should have a
list of all the changes since the previous release (not those since the
snapshot). So if there's a way of making tags that doesn't cause the
commit mails to treat them as "replacing" previous release tags, it should
be used for snapshot tags. (But the tag for the state of master with libc
and ports unified immediately after the release - the tag for the union of
2.16 libc and 2.16 ports - should probably be created the way release tags
are, for the commit mail for the 2.17 tag to be maximally meaningful.)
--
Joseph S. Myers
joseph@codesourcery.com