Preparing the Release Notes for final release

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:// or else there will be errors. These errors will be corrected later in the process.

Build the non-en-US documents

1. Switch to the translation branch with git

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://www.transifex.net/projects/p/fedora-release-notes/

3. Build the html for each of the languages to be included. Only languages at or near 100% can be included. The deadline for inclusion is two weeks prior to release. Check the L10N Schedule for details.

 publican build -f html -l (language code)

Important Information when building publican from the XML:

• Note that the language code should match the ones you see in the the git tree, not what is seen in transifex.

• Build each language individually.

If you build several languages at once, a failure in one will cause an incomplete build. Artifacts in tmp/ cause confusion.

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

5. When you get the language to build properly, push the changes back to git.

6. Purge languages that fail to build from your local copy.

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.