Immanetize (talk | contribs) |
Immanetize (talk | contribs) |
||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
==Spec File== | |||
A sample of the spec file that makes this work can be found at http://immanetize.fedorapeople.org/fedora-release-notes.spec . | |||
==create release branch== | ==create release branch== | ||
<code>git branch f19</code> | <code>git branch f19</code> | ||
Line 17: | Line 21: | ||
<code>publican update_pot</code> | <code>publican update_pot</code> | ||
<code>tx push -s</code> | <code>tx push -s</code> | ||
Line 22: | Line 27: | ||
<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=== | ||
Line 31: | Line 38: | ||
<code>publican build -l fr-FR -f html</code> | <code>publican build -l fr-FR -f html</code> | ||
<code>publican build -l nl-NL -f html</code> | <code>publican build -l nl-NL -f html</code> | ||
Fix any issue that you can, and push POs back to transifex: | Fix any issue that you can, and push POs back to transifex: | ||
<code>tx push -t</code> | <code>tx push -t</code> | ||
Remove any docs that do not build. | Remove any docs that do not build. | ||
Line 49: | Line 60: | ||
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'. | 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'. | ||
<code>git tag -a 19-3 | <code>git tag -a 19-3 -m 'updated translations for document'</code> | ||
Tags aren't push unless we ask for it, so: | |||
<code>git push --tags</code> | |||
===Order Matters=== | |||
Be sure that all of your changes are committed *and* pushed before tagging. | |||
===%{?dist}=== | |||
After reviewing http://fedoraproject.org/wiki/Packaging:DistTag I don't think we need to use the dist tag, as we did before. It seems to add more complication than benefit. | |||
===Check the tag!=== | ===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. | 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. Test the resulting URL with wget - you'll need to wget the sources to add them later, anyway. | ||
===Alpha and Beta Versions=== | ===Alpha and Beta Versions=== | ||
Alpha and beta releases should follow the naming guidelines for pre-release packages: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages | Alpha and beta releases should follow the naming guidelines for pre-release packages: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages | ||
Line 58: | Line 77: | ||
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. | 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. | ||
===Testing is important!=== | |||
I put in an embarrassing number of commits when working out this procedure. Testing with mock, and koji scratch builds, is imperative. `fedpkg mockbuild` is your friend! | |||
==Follow the packaging docs to complete submission== | |||
https://fedoraproject.org/wiki/Package_update_HOWTO | |||
*push the tarball to scm | |||
*branch build in koji | |||
*push to testing | |||
*announce availability for testing | |||
*push to stable | |||
Latest revision as of 00:37, 14 May 2013
Spec File
A sample of the spec file that makes this work can be found at http://immanetize.fedorapeople.org/fedora-release-notes.spec .
create release branch
git branch f19
- 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}
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 -m 'updated translations for document'
Tags aren't push unless we ask for it, so:
git push --tags
Order Matters
Be sure that all of your changes are committed *and* pushed before tagging.
%{?dist}
After reviewing http://fedoraproject.org/wiki/Packaging:DistTag I don't think we need to use the dist tag, as we did before. It seems to add more complication than benefit.
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. Test the resulting URL with wget - you'll need to wget the sources to add them later, anyway.
Alpha and Beta Versions
Alpha and beta releases should follow the naming guidelines for pre-release packages: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#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.
Testing is important!
I put in an embarrassing number of commits when working out this procedure. Testing with mock, and koji scratch builds, is imperative. fedpkg mockbuild
is your friend!
Follow the packaging docs to complete submission
- push the tarball to scm
- branch build in koji
- push to testing
- announce availability for testing
- push to stable