Before the final release of Fedora, the Release Notes need to be prepared for General Availability (GA). This process should also be executed prior to beta, but at beta there are often no translations and the beats may not be in the best of shape.
Development release notes are hosted on git
Prepare the en-US
The US English version of the Release notes gets packaged for the final release first. Many of the languages at 100% on Transifex will also be packaged as time allows.
Once the owner of the Release Notes determines the Beat content to be ready, complete, and free of legal issues, preparation can proceed. Currently the owner is jjmcd
Preparation process...
1. Review all of the beats to be certain new content has not been added. If necessary, add/edit the XML to reflect changes in the beats.
2. Proofread the en-US and make any important corrections. Be careful not to make unnecessary changes as these will break translations, and you should strive to minimize broken translations. Notify the translations team listn if any unavoidable changes are made.
3. Adjust the version number in Revision_History.xml. For release notes, the version is of the form x.y
- x reflects the release of Fedora
- y represents the change for XML updates, counting starting at zero for the GA
- For alpha and beta, x should be the Fedora release number minus 1, and y is 95 for Alpha and 98 for Beta. (XML release notes are generally not produced for Alpha.)
4. The RPM (and tar) version will be x.y.z
- z starts at zero for the GA with us-en
- z will get incremented as additional languages become ready
- Typically the tar file will change as new translations are added, so new tars might be produced even in the absence of XML changes.
5. Remove the draft status in Release_Notes.xml.
6. Push these changes back to git. This is important as there are likely to be updates later.
Make a clean working copy
Ensure that you have the latest translations and the RPM ultimately reflects the git contents.
Start with a clean clone in a new directory so there is no confusion as to what will be packaged.
mkdir scratch mkdir scratch/temp cd scratch git clone ssh://git.fedorahosted.org/git/docs/release-notes.git cd release-notes cp en-US/* ../temp/
Be careful to use ssh:// instead of git:// to prevent unintentional commits.
Build the non-en-US documents
1. Switch to the translation branch
git checkout --track -b f14 origin/f14
(Where the two f14's reflect the current release.)
2. Open the transifex page in a browser:
https://translate.fedoraproject.org/projects/p/docs-release-notes/c/f14/
Again, f14 should reflect the current version.
Build the html for each of the languages to be included. Usually, this means languages at or near 100%. However, the desires of L10N change from time to time, so the actual decision as to what to include should have been agreed on with L10N much earlier.
publican build -f html -l (language code)
You should build each language individually. If you build several languages at once, a failure in one will cause all to not be built, although there will be artifacts in tmp/ that can be confusing later.
Generally, some of the translations contain tagging errors, typically in languages that use non-Latin character sets. Usually these errors are fairly easy to locate. They may be corrected by editing the appropriate po file. Emacs happens to be especially smart about po files, so unless you are skilled at using Emacs on po files you may prefer to use gedit, which doesn't try to out-guess you. In addition, gedit's color coding makes it easier to spot the problems.
When you get the language to build properly, push the changes back to git.
If you find you cannot build a particular language:
rm -Rf tmp/(language code)
Build the en-US document
cp ../temp/* en-US/ publican build -f html -l en-US
Since you previously built the en-US there should be no errors.
You do not want to push the en-US back to git. This will happen the next time the POT files are updated.
Review your work
Look inside each tmp/(language code)/html directory. It should contain multiple html files. Each should contain the same names, but most importantly, there should be an index.html file. Open at least the en-US file with a browser and be sure it is the document you want. You should also open some of the other languages, although for most people, simply recognizing that it is the correct language is a problem, let alone actually reading it!
You are now ready to build the tar with doc-publican-rpm.