Re: Translations gone out for 2.16.

[Carlos O'Donell <carlos at systemhalted dot org>]

On 6/26/2012 4:37 PM, Thomas Schwinge wrote:
> 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.

Unfortunately that naming scheme doesn't match what is expected of
a GNU package e.g. http://www.gnu.org/prep/maintain/html_node/Test-Releases.html

Using a tag is also the best way to add permanency to the point at
which the snapshot was taken for the translation team. The name of a file
can be changed, or lost.

Personally I like having tags because they are easier to handle than commit ids.

>> (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.

It's not a totally write-once operation.

I feel that we should be able to create and delete tags on the remote repos. 

I have not seen any strong opinions against supporting tag deletions.

The managing of the tags by users is up to them e.g. they need to cleanup 
local tags and sync with the remote.

>> 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.

You don't see any benefit, but we have many volunteers and each should
be able to choose how they work within the framework of the community?

> 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.

Is making an official snapshot for the translation team considered
a release? It's a release to an external 3rd party that we may need
to recreate some day.
 
>> (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.

Private releases for internal uses?

> 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?

I think the fundamental question that needs to be asked is:

What are tags going to be used for?

It would appear that your answer is:

To mark official releases.

While my answer is:

To mark points of significance.

Until we agree on the use of tags we'll approach the problem from different views.

Does that make sense?

Neither one of us is wrong.

Cheers,
Carlos.