technical details for today's code and data release
# This email documents how I built today's tzcode and tzdata release. # It mostly uses POSIX shell syntax (hence the leading '#' here). # The idea is to document what I did this time, so that more of # this stuff can be done better and/or automated next time. # Here's how I built the release, on Ubuntu 12.04 x86, # starting from the unofficial public repository. git clone -n https://github.com/eggert/tz.git (cd tz git checkout ee42236d5192a0199bbac05385fe2f613b1b30e2 make check make public ) # Here's how I imported the release into the private IANA repository. # This procedure makes sense only if one has access to this repository, # which is not currently public. (cd tz-iana cp ../tz/tzcode2012c.tar.gz ../tz/tzdata2012d.tar.gz releases ln -sf releases/tzcode2012c.tar.gz tzcode-latest.tar.gz ln -sf releases/tzdata2012d.tar.gz tzdata-latest.tar.gz (cd data && tar xf ../tzdata-latest.tar.gz) (cd code && tar xf ../tzcode-latest.tar.gz) git add releases/tzcode2012c.tar.gz releases/tzdata2012d.tar.gz git commit -am'tzcode2012c and tzdata2012d' # Oops, forgot to update '.latest'. Do that now. (echo 'data tzdata2012d.tar.gz 2012-07-20' echo 'code tzcode2012c.tar.gz 2012-07-20' ) >.latest git commit -am'tzcode2012c and tzdata2012d in .latest.' ) # Here's how I created the signatures for the distributions. (cd tz gpg --detach-sign --armor -o tzcode2012c.tar.gz.sign tzcode2012c.tar.gz gpg --detach-sign --armor -o tzdata2012d.tar.gz.sign tzdata2012d.tar.gz ) # Here are the signatures themselves, generated by: (cd tz; more tzcode2012c.tar.gz.sign tzdata2012d.tar.gz.sign) :::::::::::::: tzcode2012c.tar.gz.sign :::::::::::::: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJQCPX9AAoJEO2X6Q5iqn40A+EQAKquIXzcZH92dAoJeGUO3Hfr p0pdz2wXQZvOhBZn3O2MVWZtLgER+e/qRBFi7zAm7/PAjJUwP54mVIdWnDUCGvn1 ieN/qd4qoF00d5g+xHfmo8XmogXfzjiQ6hqRqN3fSz0qzp2D9+8ckPyZyvU9hAYA OfcCB/EeSvi+U2Gg4GZzx0uhq5huhFPl6SRy+SHolAfWb0o+xxYlVsLv94jBX3rv MTEBkNPgx6FXdarfa1agvaJK4j1fWUQ056/80jfmrwZDrewTfaF2hNEDS0MAM9rC VGdbsW5mqikWEt2mFL0n1fn56bgxOFPDJOQvWt2gJ23tfAR/jhSYuQKwuAlwbwTm bTUcrxOJyyh6bUkgujHrkqSOkY+5ya6laF91ejn95tzfcTHqXOQmFT2jVBlZBhey f4pP16QHb5Q7Nf+kA//1oNDSYFrDMtfLoj/9IqLlxgzlfnwNjE+udOWgEVNGS9iF 99Bh+H0GNl1sd2xq65b7Ne+4M6pHuJzOtSCJwmJ+3+owYFs/ocIH97IAEMoFkwWJ 3LPSqLhep5OC+Z2O9OgYREhVjdPuUavz1+UF6xOroEbCAg4Act9Ok8HGlZ+q7gRk FuR/ItM+5dDFBrUQrNXRuAjR9HrcoZ9zyqMtFPzV6indI7EQwMuCtZopsi9PrC6A arMfzjlKJBJ4UCCy45wW =Dfi2 -----END PGP SIGNATURE----- :::::::::::::: tzdata2012d.tar.gz.sign :::::::::::::: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJQCPYfAAoJEO2X6Q5iqn406TwP/RHspsy44+WUFIEbfsijFkEf VW409JP0QSC0ocRe8ir1ijorNggF+j62uAQjvSSVaNb/tLy67/j+sUR5xU1/ccw6 bWM46r5P28ubSX4rs5FHQfOmOgA7LRBP+3+C6TJ8iUzSfHszZI00bOdAZWaFcQxw /hlBK83rp7vwQj2Sk9NU8tzyv1paGOcM8Ps/aL5gsZpkF48v2GQ0kDrZwazTgODD NZ4rvMg4mlNCZz6sSyTRa02B0uDkEXsNKLf/Gf3OfPIkoGdRQT6sa7qDdYXcjM1o QdTTjg+HAnCxt3CDmpNGC4K0y7aHRmZYlge1cXt0uZOvtmO9lTlSGUQIied1FuBs EaawtZw/L3Pd9bG1FeodPN/NIVQLaTss+ERU2FsgQjiOWxnaLvzSFmfBi/TrDpkW yPqqskACwhLHGLRu3uSThjAFA2OzItCdqbwHfMMNoo0aXL85ZipUpH3CnhDwOQxn I3s43HLepBpJi7RofR4KtolnRvlu2rfEAqmhUOhWk1ACVghI4ev2papQ5boucf0N B93AUQnv6WO9WgmeWrQ7CnYPoydBIlOYdjKmiOZ9c45qFsHEX76ZfUY6sbi3sLE/ mxOsYFZLBf5my8APmyespgO+WTXFCbMHBKbeKQRuchRuXYi5/72CxVJ1TZEt+aMd 0PJmnu0eg3TKYTE6/vX8 =eKib -----END PGP SIGNATURE-----
On 2012-07-20 07:22, Paul Eggert wrote:
# This email documents how I built today's tzcode and tzdata release. # It mostly uses POSIX shell syntax (hence the leading '#' here). # The idea is to document what I did this time, so that more of # this stuff can be done better and/or automated next time.
# Here's how I built the release, on Ubuntu 12.04 x86, # starting from the unofficial public repository. git clone -n https://github.com/eggert/tz.git (cd tz git checkout ee42236d5192a0199bbac05385fe2f613b1b30e2
It's probably useful to tag the release before checking out. I suppose at the moment the tag would need to combine the tzcode and tzdata version numbers, e.g. "tzcodeAAAAb_tzdataCCCCd". Or if you want the combined tags to increase monotonically, something like "tzYYYYz_codeAAAAb_dataCCCCd" where YYYYz is the maximum of "AAAAb" and "CCCCd". You could have additional tags with just the tzcode version and just the tzdata version. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Fri, Jul 20, 2012 at 11:36 AM, Ian Abbott <abbotti@mev.co.uk> wrote:
It's probably useful to tag the release before checking out. I suppose at the moment the tag would need to combine the tzcode and tzdata version numbers, e.g. "tzcodeAAAAb_tzdataCCCCd". Or if you want the combined tags to increase monotonically, something like "tzYYYYz_codeAAAAb_dataCCCCd" where YYYYz is the maximum of "AAAAb" and "CCCCd". You could have additional tags with just the tzcode version and just the tzdata version.
To that end I'd be happy to generate tags (with the original release comments) for the repository in github. Would there be an interest in that? Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Kevin Lyda <kevin@ie.suberic.net> writes:
On Fri, Jul 20, 2012 at 11:36 AM, Ian Abbott <abbotti@mev.co.uk> wrote:
It's probably useful to tag the release before checking out. I suppose at the moment the tag would need to combine the tzcode and tzdata version numbers, e.g. "tzcodeAAAAb_tzdataCCCCd". Or if you want the combined tags to increase monotonically, something like "tzYYYYz_codeAAAAb_dataCCCCd" where YYYYz is the maximum of "AAAAb" and "CCCCd". You could have additional tags with just the tzcode version and just the tzdata version.
To that end I'd be happy to generate tags (with the original release comments) for the repository in github. Would there be an interest in that?
The tags should be signed as well. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
On Fri, Jul 20, 2012 at 12:48 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
The tags should be signed as well.
True, and that I can't do. But I can generate a script to do all the tag commands so Paul can run them himself and sign them with his key. Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Ian Abbott <abbotti@mev.co.uk> writes:
It's probably useful to tag the release before checking out. I suppose at the moment the tag would need to combine the tzcode and tzdata version numbers, e.g. "tzcodeAAAAb_tzdataCCCCd". Or if you want the combined tags to increase monotonically, something like "tzYYYYz_codeAAAAb_dataCCCCd" where YYYYz is the maximum of "AAAAb" and "CCCCd". You could have additional tags with just the tzcode version and just the tzdata version.
Yeah, I would just make two tags, one for tzcode and one for tzdata. They will probably frequently come in pairs, but that's fine. (Purely a matter of bikeshed-painting, but I would tend to use tzcode/AAAAb and tzdata/CCCCd for the tags.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
What would be the typical use cases for tags? I'd like to see that, before adding tags of a particular stripe.
On Sat, Jul 21, 2012 at 6:50 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
What would be the typical use cases for tags? I'd like to see that, before adding tags of a particular stripe.
In git it's quite easy to hop between various revisions. I'll be taking my historical tz repo down soon, but using it as an example, you'll see each release is tagged: https://github.com/lyda/tz So you can quickly go from https://github.com/lyda/tz/tree/tzdata2010f to https://github.com/lyda/tz/tree/tzdata1999a On the command line you can just do: git checkout tzcode1999a And browse the code from that release there. You can quickly check the diffs between versions: git diff tzcode1999b...tzcode1999d Say someone tells you that the last version of the code without bug X was tzcode2010c. You write a script that will build the code and run a test that exits 0 if OK, 1 if bad. You could do the following: git checkout master git bisect start git bisect bad git bisect good tzcode2010c git bisect run ~/test-script.sh It will find the first occurrence of the bug which should help you identify the change that caused the problem. You can also use it to see when things first got added. For example if you were to put this in ~/test-script.sh: ---- #!/bin/bash if [[ ! -f zone.tab ]]; then exit 0 fi if grep -q Africa/Luanda zone.tab; then exit 1 else exit 0 fi ---- and then run: git checkout master git bisect start git bisect bad git bisect good tzcode93 git bisect run ~/test-script.sh You'd discover that Africa/Luanda was added to zone.tab in the tzdata96k release. Yes, you can do this without tags, but they're easier to remember / make sense of than git revision numbers (in this tree that release is e093ff07e6cc1d6e8bf0b6b3472f4a93a0a7c560 for example). Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
On Sat, 21 Jul 2012, Paul Eggert wrote:
On 07/21/2012 02:31 AM, Kevin Lyda wrote:
On the command line you can just do: git checkout tzcode1999a
But that checks out both code and data, right?
Hmm, not quite. As you have code and data in the same repository, the "checkout" will just set the state of your local repository to the commit that the tag refers too. You can have multiple tags for one commit very easily. If you want to avoid that, then code and data should live in a repository of themselves.
Isn't that confusing?
A little, but git is a bit confusing anyway, so I don't think this is a problem. A tag is just a symbolic name and I'd love to have one added for each release of both the code and data package. cheers, Derick
Derick Rethans <tz@derickrethans.nl> writes:
On Sat, 21 Jul 2012, Paul Eggert wrote:
On 07/21/2012 02:31 AM, Kevin Lyda wrote:
On the command line you can just do: git checkout tzcode1999a
But that checks out both code and data, right?
Hmm, not quite. As you have code and data in the same repository, the "checkout" will just set the state of your local repository to the commit that the tag refers too. You can have multiple tags for one commit very easily.
But it _does_ check out both code and data. You order tzdataX, and get tzdataX and whatever tzcode corresponds to it.
If you want to avoid that, then code and data should live in a repository of themselves.
Yeah... conceptually, tzcode and tzdata are different projects that just happen to have similar release schedule. I guess one could actually invoke some sort of git filter-branch magic to separate the two sub-repositories that make up the current "tz" super-repository. I'm not sure it's worth the hassle though, for the project the size of zoneinfo. The whole setup is not that confusing after all. But it seems to indicate that we should go with two-faceted tags (tz_codeX_dataY), to make this clear. Thanks, PM
But it seems to indicate that we should go with two-faceted tags (tz_codeX_dataY), to make this clear.
I'd disagree. That would mean that to check out codeX, you would need to enumerate the list of tags to determine a matchign dataY. Better, I think, to have a codeX tag and a dataY tag and suffer the fact that a checkout of one will give you a close-but-potentially-unexpected other. --jhawk@mit.edu John Hawkinson
On Sun, 22 Jul 2012, John Hawkinson wrote:
But it seems to indicate that we should go with two-faceted tags (tz_codeX_dataY), to make this clear.
I'd disagree. That would mean that to check out codeX, you would need to enumerate the list of tags to determine a matchign dataY. t Better, I think, to have a codeX tag and a dataY tag and suffer the fact that a checkout of one will give you a close-but-potentially-unexpected other.
Exactly. However, we could always add the tz_codeX_dataY as *well* of course... tags are cheap! cheers, Derick
On Mon, Jul 23, 2012 at 11:26 AM, Derick Rethans <tz@derickrethans.nl> wrote:
Exactly. However, we could always add the tz_codeX_dataY as *well* of course... tags are cheap!
Exactly. The two projects are merged in one repository. I'm not really sure it helps to split them. When checking out tzcodeYYYYr it's nice to see what tzinfo looked like. Historically this is how the release process worked on the repository side. It might be nice to change in the future, but based on having the two projects in a single repository it seems like the logical method. Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Derick Rethans <tz@derickrethans.nl> writes:
On Sun, 22 Jul 2012, John Hawkinson wrote:
But it seems to indicate that we should go with two-faceted tags (tz_codeX_dataY), to make this clear.
I'd disagree. That would mean that to check out codeX, you would need to enumerate the list of tags to determine a matchign dataY. t Better, I think, to have a codeX tag and a dataY tag and suffer the fact that a checkout of one will give you a close-but-potentially-unexpected other.
Exactly. However, we could always add the tz_codeX_dataY as *well* of course... tags are cheap!
Please don't. Cheap is fine, but there's also visual clutter in gitk. I'm in favor of separated tags as well, btw. It may not fit the reality of the underlying source, but those two-headed tags seem convoluted. Thanks, PM
On 07/20/2012 10:45 AM, Russ Allbery wrote:
I would tend to use tzcode/AAAAb and tzdata/CCCCd for the tags.
What is the advantage of using a slash in the tags? Sorry, I don't know the details of tagging in git; I tend to not use tags myself.
I would just make two tags, one for tzcode and one for tzdata. They will probably frequently come in pairs, but that's fine.
Someone else (I forgot who, sorry) said that there is really just one version number, not two, so therefore there are gaps in one or the other versions' numbering. For example, there was no tzcode2011h release because the code didn't change between 2011g and 2011h. In that case, I messed up with the latest release, since I thought that the code and data version numbers were independent. I'll send a proposed patch to the mailing list shortly (PATCH 4/4) to switch back to a single version number, so that the next releases are 2012e for both code and data. This would also suggest that we have just one set of tags in the repository, tz/2012e or tz2012e say, depending on whether that slash is helpful.
On Wed, 25 Jul 2012, Paul Eggert wrote:
On 07/20/2012 10:45 AM, Russ Allbery wrote:
I would tend to use tzcode/AAAAb and tzdata/CCCCd for the tags.
What is the advantage of using a slash in the tags? Sorry, I don't know the details of tagging in git; I tend to not use tags myself.
Tags are just freeform descriptors, and have no real special meaning.
This would also suggest that we have just one set of tags in the repository, tz/2012e or tz2012e say, depending on whether that slash is helpful.
The / has no advantage in this case. It would say that it would just make it more annoying to deal with f.e. in case you want to use a directory for each tag (with / being the directory separator). cheers, Derick
Derick Rethans <tz@derickrethans.nl> writes:
On Wed, 25 Jul 2012, Paul Eggert wrote:
On 07/20/2012 10:45 AM, Russ Allbery wrote:
I would tend to use tzcode/AAAAb and tzdata/CCCCd for the tags.
What is the advantage of using a slash in the tags? Sorry, I don't know the details of tagging in git; I tend to not use tags myself.
Tags are just freeform descriptors, and have no real special meaning.
Right. I use slashes in tags to create namespaces when there are multiple types of tags happening in the same repository, since everyone is used to slash as a directory separator creating namespaces for files. So, for example, a repository in which I do both upstream development and Debian packaging has a set of release/* tags for the upstream releases and debian/* tags that correspond to the Debian packages. It's just a (somewhat arbitrary) convention.
This would also suggest that we have just one set of tags in the repository, tz/2012e or tz2012e say, depending on whether that slash is helpful.
The / has no advantage in this case. It would say that it would just make it more annoying to deal with f.e. in case you want to use a directory for each tag (with / being the directory separator).
Yes, once you only have one set of tags, you no longer have multiple tags that you want to put into distinguished namespaces, so there's no need for the slash. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
participants (8)
-
Andreas Schwab -
Derick Rethans -
Ian Abbott -
John Hawkinson -
Kevin Lyda -
Paul Eggert -
Petr Machata -
Russ Allbery