Re: Translations gone out for 2.16.

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Tue, 26 Jun 2012 11:06:45 -0400, Carlos O'Donell <carlos_odonell@mentor.com> wrote:
> On 6/26/2012 5:19 AM, Thomas Schwinge wrote:
> > On Mon, 25 Jun 2012 21:41:12 -0400, "Carlos O'Donell" <carlos@systemhalted.org> wrote:
> >> I've checked in the libc.pot changes for trunk.
> >>
> >> 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
> > replying to, I had issued a Âgit fetch sourceware and wondered what that
> > new Âglibc-2.16-tps tag was that had been pulled off of sourceware.
> 
> The tag will represents a marker for the commit at which the translations
> are accurate. The tag was used in conjunction with `make dist' to produce
> a snapshot tarball for the translation team. It seemed sensible to me to
> create a tag for this particular usage.

In my idea, what Âmake dist does by default is enough for this purpose:

    $ make dist
    [...]
    make[2]: Leaving directory `/media/boole-data/home/thomas/tmp/source/glibc/git'
    Distribution version glibc-2.15-1211-ga9fa33b
    make[2]: Entering directory `/media/boole-data/home/thomas/tmp/source/glibc/git'
    git archive --prefix=glibc-2.15-1211-ga9fa33b/ glibc-2.15-1211-ga9fa33b > glibc-2.15-1211-ga9fa33b.tar.new
    [...]
    md5sum glibc-2.15-1211-ga9fa33b.tar.bz2 glibc-2.15-1211-ga9fa33b.tar.gz glibc-2.15-1211-ga9fa33b.tar.xz
    520363c3023dc505a30213a7d659e5cd  glibc-2.15-1211-ga9fa33b.tar.bz2
    8bc7a875bf39d7bf57a162504b02eca3  glibc-2.15-1211-ga9fa33b.tar.gz
    88bb535f872f11c69aee4950bc0a97a2  glibc-2.15-1211-ga9fa33b.tar.xz
    rm glibc-2.15-1211-ga9fa33b.tar
    make[2]: Leaving directory `/media/boole-data/home/thomas/tmp/source/glibc/git'
    make[1]: Leaving directory `/media/boole-data/home/thomas/tmp/source/glibc/git'

The tarball's version is set to how Âgit describe labels the current
revision, which is based on the previous tag suffixed with Âthe number of
additional commits on top of the tagged object and the abbreviated object
name of the most recent commit -- which already uniquely and
meaningfully identifies the revision.

> (2) Pros and cons of lots of tags?
> 
> Can you talk a little bit more about the pros and cons of limiting
> our tagging?

Others already commented on this, and as you have figured out, pushing a
tag is essentially a write-once operation -- that is, even if you manage
to delete them from the sourceware repository (which surely is
technically possible given direct access), a user's next Âgit fetchÂ/Âgit
pull will *not* overwrite his local tag.

> I would like to allow *anyone* to push tags, and use them for whatever
> novel purposes they have.

A Âlightweight tag just assigns a different name to a SHA1 -- like a
branch but write-once, and as such I don't see any benefit in prefering
it over a branch except -- maybe... -- in cases where the write-once
property can be useful, for example to "close" a branch.

The more heavy-weight annotated/signed tag conveys additional
information, a description and/or signature, and I see its prime (and
only?) use in creating "official" releases.

> (3) Create a tag namespace?
> 
> However, it seems that we may need to develop a tag hierarchy like
> we have with the branch namespaces.

Hmm, I don't really know what for I would be pushing arbitrary tags.

But there are surely folks who are more into this kind of Git usage than
I am -- for example, David with his Linux kernel experience?


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature