From Fedora Project Wiki
(Push POTs, Pull POs)
(Push POTs, Pull POs)
Line 17: Line 17:
<code>publican update_pot</code>
<code>publican update_pot</code>
<code>tx push -s</code>
<code>tx push -s</code>
Line 22: Line 23:
<code>tx pull fr</code>
<code>tx pull fr</code>
<code>tx pull nl</code>
<code>tx pull nl</code>
===reusing tx configs===
===reusing tx configs===

Revision as of 23:57, 8 March 2013

create release branch

git branch f19

  1. Pull en_US source from master

At first, the release branch should mirror the master branch. Changes are pulled over to the release branch for release milestones - alpha, beta, and GA release. Active work is done in the master branch. We can check out a file from the master branch to apply.

git checkout f19

git checkout master -- file.xml

ensure source builds

publican build -l en-US -f html

You're doing this often anyway, right?

Push POTs, Pull POs

Early in the milestone cycle, push the source to transifex.

publican update_pot

tx push -s

After translation has been performed, check the transifex dashboard and pull *only* completed translations.

tx pull fr

tx pull nl

reusing tx configs

Please commit your tx configuration! initializing tx for a document can be tedious and error prone - we should not have to do it more than once.

test to ensure translations build

Of course, all languages must build. Test that:

publican build -l fr-FR -f html publican build -l nl-NL -f html Fix any issue that you can, and push POs back to transifex: tx push -t Remove any docs that do not build.

Prep the branch

Add the source and POs to the git repo. git add {en-US,fr-FR,nl-NL}/* Pull over the barebones desktop file and language index git checkout master -- build/{document.desktop,index.html} <code>git commit -a -m 'adding langs'

review the regex

The sample spec file contains regular expressions to extract certain information. These regular expressions should be fine once adapted to a specific document. Initially, they will probably have to be adjusted.

tag the release branch

The end result will be an RPM with a filename of the form %{name}-%{release}-%{version}.rpm and we want our git tag to match. For example, if building a package for f19 for the third time, the tag could be '19-3.fc19'.

git tag -a 19-3.fc19 -m 'updated translations for document'

Check the tag!

The spec file should be consulted to get the correct tag information. If in doubt, bump the version in the spec file and run `rpmlint` on it to see how the variables are substituted.

Alpha and Beta Versions

Alpha and beta releases should follow the naming guidelines for pre-release packages:

wget the source and perform a mock build

Test with rpmlint again. Sources can take a a while to become available for download, so rpmlint may complain unjustly. wget the tar.bz2 file described in rpmlint's output to verify the release is tagged correctly and the file is available.

Perform a local build, and a mock build.

rpmlint resulting package

push the tarball to scm

scratch build in koji

branch build in koji

push to testing

announce availability for testing

push to stable