From Fedora Project Wiki

No edit summary
m (internal link cleaning)
 
(13 intermediate revisions by 2 users not shown)
Line 2: Line 2:




Before the final release of Fedora, the Release Notes need to be prepared for release.  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.
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 [http://git.fedorahosted.org/git/?p=docs/release-notes.git hosted on git]
 


==Prepare the en-US==
==Prepare the en-US==


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.
The US English version of the Release notes gets packaged for the final release first. Many of the languages at 100% on [https://translate.fedoraproject.org/projects/p/docs-release-notes/c/f14/ 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 [[User:Jjmcd|jjmcd]]


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.
Preparation process...


Adjust the version number in Revision_History.xml.  For release notes, the version is of the form x.y, the x reflects the release of Fedora and y represents the change ordinal for the XML.  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.
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.


The RPM (and tar) version will be x.y.z where z represents the tar file ordinalTypically the tar file will change as new translations are added, so new tars might be produced even in the absence of XML changes.
2. Proofread the en-US and make any important correctionsBe careful not to make ''unnecessary'' changes as these will break translations, and you should strive to minimize broken translations. Notify [https://admin.fedoraproject.org/mailman/listinfo/trans the translations team list]n if any unavoidable changes are made.


Remove the draft status in Release_Notes.xml.
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.)


Don't forget to push these changes back to git.
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==
==Make a clean working copy==


To ensure that you have the latest translations and the RPM ultimately reflects the git contents it is best to start with a clean clone in a clean directory so there is no confusion as to what will be packaged.
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
Line 29: Line 47:
   cp en-US/* ../temp/
   cp en-US/* ../temp/


Note that, in a perfect world, you would not need to push anything back to git, so you could use the <code>git://</code> form of the clone, but invariably there will be errors to correct and these should be pushed back, so the <code>ssh://</code> form is preferred.
Be careful to use <code>ssh://</code> instead of <code>git://</code> or else there will be errors. These errors will be corrected later in the process.


==Build the non-en-US documents==
==Build the non-en-US documents==


Switch to the translation branch
1. Switch to the translation branch with git


  git checkout --track -b f14 origin/f14
  git checkout --track -b f14 origin/f14
Line 39: Line 57:
(Where the ''two'' f14's reflect the current release.)
(Where the ''two'' f14's reflect the current release.)


Open the transifex page in a browser
2. Open the transifex page in a browser:


https://translate.fedoraproject.org/projects/p/docs-release-notes/c/f14/
https://www.transifex.net/projects/p/fedora-release-notes/


Again, f14 should reflect the current version.
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|L10N Schedule]] for details.


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)


  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 [http://git.fedorahosted.org/git/?p=docs/release-notes.git;a=tree git tree], not what is seen in  [https://translate.fedoraproject.org/projects/p/docs-release-notes/c/f14/ transifex.]
 
* Build each language individually.
If you build several languages at once, a failure in one will cause an incomplete build. Artifacts in <code>tmp/</code> cause confusion.
 
4. Address tagging errors - typically in languages that use non-Latin character sets. 


You should build each language individuallyIf you build several languages at once, a failure in one will cause all to not be built, although there will be artifacts in <code>tmp/</code> that can be confusing later.
Usually these errors are fairly easy to locate.  They may be corrected by editing the appropriate po fileEmacs 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.


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.
5. When you get the language to build properly, push the changes back to git.


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:
If you find you cannot build a particular language:
Line 70: Line 95:
==Review your work==
==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.
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.
You are now ready to build the tar with doc-publican-rpm.
[[Category:Docs Project process]]

Latest revision as of 21:18, 19 September 2016


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.