nightmorph 07/10/19 02:22:25 Added: handbook-release.xml Log: added new guide on how to update the handbook and all other related documentation for each new release. it is a huge task, and this document will assist those who have the unenviable job of trying to do the release, often single-handedly.
Revision Changes Path 1.1 xml/htdocs/proj/en/gdp/doc/handbook-release.xml file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml?rev=1.1&view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml?rev=1.1&content-type=text/plain Index: handbook-release.xml =================================================================== <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml,v 1.1 2007/10/19 02:22:25 nightmorph Exp $ --> <guide link="/proj/en/gdp/doc/handbook-release.xml"> <title>Handbook Release Guide</title> <author title="Author"> <mail link="[EMAIL PROTECTED]">Joshua Saddler</mail> </author> <abstract> This guide details the process for updating the handbooks and related documentation for each new Gentoo Linux release. </abstract> <!-- The content of this document is licensed under the CC-BY-SA license --> <!-- See http://creativecommons.org/licenses/by-sa/2.5 --> <license/> <version>1.0</version> <date>2007-10-18</date> <chapter> <title>Introduction</title> <section> <title>Purpose</title> <body> <p> This document is intended to help the handbook release coordinator (and/or other GDP members and contributors) tackle the massive task of bringing all the handbooks and related documentation up-to-date for the latest Gentoo Linux release. </p> <p> It's designed to take some of the pain and stress out of a free-form, unplanned process and instead introduce a bit of logical order. All too often, the burden of updating all documentation tends to fall on just one single person (as this author can attest to on multiple occasions). Whether or not that happens for a particular release, this guide still provides a smart, sensible plan for getting docs ready to go. </p> <p> This document will provide guidelines on <e>what</e> to do and <e>when</e> to do it, though these are just guidelines; there are few hard rules, except when it comes to GuideXML coding and commit rules, as explained in such documents as the the <uri link="/doc/en/xml-guide.xml">GuideXML Guide</uri> and the <uri link="/proj/en/gdp/doc/doc-tipsntricks.xml">Documentation Tips and Tricks</uri>. </p> </body> </section> </chapter> <chapter> <title>What to Monitor</title> <section> <title>Release dates</title> <body> <p> In order to plan your tasks and estimate completion dates for TODO items, you'll need to have an idea of when the next release is. Gentoo operates on a so-called <e>rolling release</e> schedule. Packages are updated constantly; a new release of Gentoo is merely an update to the installation media, stages, Portage snapshots, and so on. However, this always entails a huge change in the Installation Handbook and other related documentation, as they have to be brought in line with the new installation media. </p> <p> New releases occur about every 6 months, though this is not set in stone, so be sure to constantly check the <uri link="/proj/en/releng/index.xml">release roadmap</uri> for updates. Also be sure to check with Release Engineering (releng) team members in person as release time grows nearer, just in case the roadmap hasn't been updated. </p> </body> </section> <section> <title>Handbooks</title> <body> <p> By far the most important items to update are the handbooks. </p> <ol> <li> <uri link="doc/en/handbook/handbook-x86.xml?part=1">Installation Handbook</uri>: the biggest handbook. This is your first priority, as it's where users go when they want to install Gentoo. The handbook for each architecture requires time, energy, and TLC. The handbook comes in two flavors, <e>networked</e> and <e>networkless</e>. Both are of about equal priority, though just before release, you'll want to focus a bit more on keeping the networkless handbook completely ready to go, as releng will need tarballs of it to put on the LiveCDs in advance of the actual release date. </li> <li> <uri link="/doc/en/handbook/handbook-x86.xml?part=2">Portage Handbook</uri>: Doesn't change nearly as often as the Installation Handbook, but still needs to be updated for new configuration files and names, such as <path>/etc/make.conf</path> and <path>/etc/conf.d/</path> changes. The <uri link="/doc/en/handbook/handbook-x86.xml?part=3">other Portage Handbook</uri> is more in-depth. Check with the baselayout and Portage maintainers to make sure the information is up-to-date. </li> <li> <uri link="/doc/en/handbook/handbook-x86.xml?part=4">Network Handbook</uri>: This will be updated about as often as the major networking configuration sections of the Installation Handbook are updated, as some of the information is similar. Again, check with the baselayout and Portage maintainers to make sure the information is current. </li> </ol> <note> Not all the Portage/Networking handbook files will change, so it may be better to just copy over only the ones you <e>know</e> will be changing when you start updating them. Be sure of which files actually need to be changed. Again, communication and coordination! </note> <p> Variables and conditional includes are a lifesaver. Use them! Arch-specific items that constantly change, such as ISO size, recommended CFLAGS, kernel versions, etc. are kept in the handbook-$arch files, right at the top. Releng will know about CD boot parameters, media/download size, and minimum system requirements, as well as available media and their filenames. Arch teams will know about CFLAGS and kernel names & configuration, as well as suggested partitioning schemes and specific tools to emerge/use. </p> <p> Whenever possible, try to get arch team members to help you keep track of all the changing information from release to release. See if they have a dedicated liaison to assist with verifying documentation changes; it's even better if they have someone who can submit GuideXML patches, so don't hesitate to ask! So be sure to CC the arch teams on the handbook release tracker bug to keep them in the loop. </p> <p> Sometimes releases will offer enough changes that a new chapter or even a whole new handbook has to be written, or may even be removed. As much as possible while remaining <e>practical</e>, try not to duplicate information across separate arch handbook files. Instead, see if you can combine them into a single file through smart use of conditional includes. When these kinds of additions/subtractions occur, you'll need to make the appropriate alterations to the handbook-$arch files. </p> </body> </section> <section> <title>Other documents</title> <body> <p> Besides the handbooks, you will also need to simultaneously update the following documents to keep them in line with the handbooks. Docs come and go but these are currently the most critical files to keep track of. </p> <ul> <li> <b>Quick Install Guides</b>, including the ones for x86, Sparc, FreeBSD, and any other arch for which we have a quick install guide in <path>/doc/en/</path>. This includes any <uri link="/doc/en/altinstall.xml">Alternative Installation Method</uri>-type guides, <uri link="/doc/en/lvm2.xml">LVM2</uri> guides, <uri link="doc/en/gentoo-x86-tipsntricks.xml">Installation Tips & Tricks</uri>, and the like. </li> <li> <b>FAQs</b>, including the general <uri link="/doc/en/faq.xml">FAQ</uri> and arch-specific FAQs, such as for AMD64, PPC, Sparc, etc. Also included here are any arch-specific requirements or compatibility guides, such as for MIPS. Anything for which support may change from release to release; you will need to contact the various arch teams to find out. </li> <li> <uri link="/doc/en/liveusb.xml">The LiveUSB HOWTO</uri>, for the folks that want to use a USB key instead of installation CDs. Check to make sure that boot parameters are still correct, as well as the process of creating the media. </li> <li> <b>Upgrade guides</b>, such as the <uri link="/doc/en/gentoo-upgrading.xml">Gentoo Upgrading Guide</uri>, as this doc contains profile upgrading information. Most releases include new profiles and deprecate or remove old profiles. Also, any changes introduced by baselayout between releases will have their upgrading information covered here. </li> <li> <uri link="/doc/en/kernel-config.xml">Kernel Configuration Guide</uri>. Keep the available and recommended options in this file synchronized with what's in the Installation Handbook. </li> <li> <path>metadoc.xml</path>, which will contain updated links to the current handbook files, both networked and networkless </li> </ul> </body> </section> </chapter> <chapter> <title>Committing</title> <section> <title>General guidelines</title> <body> <p> Remember, before you commit any change to a document, validate the file with <c>xmllint --valid --noout</c>. Quality! Aim for technical and process perfection. It <e>will</e> save you grief when it comes time for the actual release. </p> <p> Avoid mixing spelling, grammar, or GuideXML coding style fixes (non-content changes) with procedural/informational fixes (content changes), otherwise translators will get out their knives and come for you. You don't want that. Try committing content fixes first, then the non-content fixes. </p> <p> Don't bother bumping dates when you're working on your offline drafts. Save the final date bump for the final "live" commit. However, you may want to make the correct version bump ahead of the "live" commit, just to get it out of the way. It's also a handy indication of whether or not you've remembered to touch the file. When you're ready for the final commit, be sure to verify the version and dates for each file. (Bring some caffeine; the process is tedious but necessary.) </p> <p> As much as possible, try to keep section text and layout (including order) identical across the other arch handbooks, especially for shared content. </p> <p> If you do include <-- TODO comments --> in the docs as notes to yourself, be sure to remove them before committing the finished document; don't clutter it up. </p> <p> When you're ready for the "live" commit, don't forget to remove any draft disclaimers from file links. </p> </body> </section> </chapter> <chapter> <title>Suggested Procedures</title> <section> <body> <p> The following procedures do not <e>have</e> to be done in the specified order, but they are recommended. They will help you make efficient use of your time, with as few errors as possible. This procedure order (or something close to it ;)) has worked pretty well for the last few releases. </p> <impo> The <e>very first</e> thing you should do is <e>open a handbook release tracker bug</e>. CC the arch teams, releng, and anyone else essential to the process of updating the handbooks; you'll need their help for the content, as well as the help of your fellow GDP members to put it all together. Once that's done, you can get down to the business of actually editing the documents. Keep the GDP and other project members informed about your progress by posting status updates to the bug and sending out email as necessary. </impo> </body> </section> <section> <title>Editing drafts</title> <body> <p> Start with the installation handbooks: </p> <ol> <li> Create the new networkless handbook directory; e.g. <path>handbook/2007.1/</path> </li> <li> Copy all current networkless handbook files into this new networkless directory. It's okay that this is actually a "live" directory -- you just won't be linking any of the files from index pages. </li> <li> Copy the current networked handbook files into <path>handbook/draft/</path> </li> <li> Commit these additions. Make it a straight copy with <b>no</b> modifications! Otherwise, translators will hate you for making it hard to follow your changes. </li> <li> Edit the networkless handbook-$arch.xml pages, making sure they have the draft disclaimer in their file link </li> <li> Go through and renumber old release names/numbers to the upcoming one, e.g. 2007.0 --> 2007.1. Now is also a good time to make the major version mumber bump for each page. Each new release gets a major <version> number bump. Thus, 2007.0 references in <path>hb-install-kernel.xml</path> become 2007.1 and the file's <version> gets bumped from 7.4 to 8.0. If it's 4.3, it becomes 5.0, and so on. </li> <li> Begin making content and non-content changes to the files, being careful not to mix the two. Remember that most changes will apply to both networked and networkless handbooks, but not all, so be careful when you're doubling up your commits. Also, watch out for handbook changes that also need to be propagated to non-handbook files, such as FAQs. </li> <li> Make the necessary changes to non-handbook files, but try to keep those changes offline, as explained below. </li> </ol> <impo> Be careful when working on files outside of <path>/handbook/</path>! If the updated information you're adding to these documents won't hurt users <e>now</e> and is not otherwise premature, go ahead and commit those changes to the live documents. Otherwise, you should keep your changes offline, on your local machine only. Also, be careful that you aren't altering the handbook files inside the top-level <path>/handbook/</path> directory; make sure you're committing your changes only to <path>/handbook/draft/</path> and <path>/handbook/$new-release/</path>. </impo> </body> </section> <section> <title>Preparing the on-disc networkless handbooks</title> <body> <p> You'll need to have the networkless handbooks ready some days in advance of the actual release date, as releng will be placing them into the disc ISOs ahead of time. Obviously, you must keep the networkless handbooks as current and perfect as possible; ideally with version bump, and even a date bump, just before it comes time to roll them up into the tarball. </p> <p> Unfortunately, the GDP no longer has a working script to convert handbooks into the HTML version that goes on the disc. Instead, use the rendered HTML source code online in <path>/handbook/$new-release/</path>. Download the all-in-one <b>Printable</b> version of the required arch handbook's source code using your favorite browser and save it as <path>handbook-<arch>.html</path>. The following example uses the Sparc handbook. </p> <pre caption="Creating the on-disc handbook"> <comment>(Create the directory you'll be tarring up)</comment> $ <i>mkdir -p handbook-sparc/handbook/html/css</i> $ <i>cd handbook-sparc/handbook/html/</i> <comment>(Move the HTML file here)</comment> $ <i>mv ../../../handbook-sparc.html ./</i> <comment>(Download Gentoo's CSS)</comment> $ <i>wget http://www.gentoo.org/css/main.css -O css/main.css</i> </pre> <p> Next you'll need to edit the HTML file with your favorite editor. Change the CSS link in the document's head to <path>css/main.css</path> as shown: </p> <pre caption="Editing handbook-sparc.html"> <link title="new" rel="stylesheet" href="<i>css/main.css</i>" type="text/css"> </pre> <p> Save your changes, then tar up the top-level <path>handbook-sparc</path> directory you created. Save it as <path>handbook-sparc.tar.gz</path>, then pass it on to releng. Repeat for each architecture that has a networkless installation handbook. </p> </body> </section> <section> <title>Committing, including the final release</title> <body> <ol> <li> Once you think you're ready for the release, go back through each of your files and verify that the XML is valid and well-formed. <brite>Fix any errors now</brite>, not when you go to make the final commit. </li> <li>Verify that the file version and date have been properly bumped</li> <li> Remove the draft disclaimers from the networkless handbook-$arch index pages. </li> <li>Remove any <-- TODO --> comments or other notes to yourself.</li> <li> Make sure that you've tarred up the networkless handbooks and given them to releng for the install CDs, as outlined previously. </li> <li> Move the files from <path>handbook/draft/</path> into <path>handbook/</path>, overwriting the old ones and removing outdated files where necessary. </li> <li>Make sure <path>metadoc.xml</path> is correct</li> <li> Manually verify that each and every single file you touched is the way you want it. (Got your caffeine handy?) </li> <li> Make sure you haven't forgotten any patches or content from the handbook release tracker bug. </li> <li> Once you're satisfied that everything is ready, <c>cd</c> into the topmost directory, usually <path>/doc/en/</path> and make an <e>atomic</e> commit; that is, commit everything at once so it all goes "live" at the same time. </li> <li> Communicate with your fellow developers: send announcements/status updates to the tracker bug and to any required mailing lists </li> <li><e>Take a deep breath</e></li> <li> Go back and re-examine every single file you just committed. Have you been watching gentoo-doc-cvs? ;) There's almost always something that was overlooked; now is the time to make sure you aren't forgetting any content. </li> </ol> <p> Eventually, once the release is out the door and everything is more-or-less straightened out, you can go ahead and close that tracker bug. Feels good, doesn't it? Now you get to fix the user and developer bug reports as they come in! </p> <p> And then, before you know it, it'll be time to begin the release cycle <e>all over again</e> . . . :) </p> </body> </section> </chapter> <chapter> <title>Pre-release Quick Checklist</title> <section> <body> <p> Here's an abbreviated version of most of the above, to be done immediately before the final "live" commit: </p> <ul> <li> Networked handbook files in <path>handbook/draft/</path>. Check the handbook-$arch pages. Fix inter/intra-document links, release version numbers, and file/date revbumps. </li> <li> The handbook <path>index.xml</path> pages; check the listed translations and other info </li> <li> Networkless handbook files in <path>handbook/$new-release/</path>. Same checks as the networked files. Remove draft disclaimers. </li> <li> Networking handbook check for <path>handbook/draft/</path>: current and consistent </li> <li> Portage handbook check for <path>handbook/draft/</path>: current and consistent </li> <li> Security handbook check for <path>/doc/en/security/</path>: this is low-maintenance, but check anyway </li> <li> Check <path>/doc/en/</path> for pending changes to these top-level files. Includes quickinstalls, FAQs, upgrade guides, kernel guides, etc. </li> <li> <path>metadoc.xml</path> check: verify the files that make up the new release. Overwrite the old ones listed and revbump metadoc. </li> <li> Validate every single file in <path>/doc/en/</path>, <path>handbook/draft/</path>,and <path>handbook/$new-release/</path> with <c>xmllint --valid --noout</c>. Yes, again. Fix errors. </li> <li>Check the handbook release tracker bug for any remaining tasks</li> <li><c>cd</c> to <path>/doc/en/</path> and make your atomic commit.</li> </ul> </body> </section> </chapter> </guide> -- [EMAIL PROTECTED] mailing list
