* [gentoo-doc-cvs] cvs commit: handbook-release.xml
@ 2007-10-19 2:22 Josh Saddler
0 siblings, 0 replies; 3+ messages in thread
From: Josh Saddler @ 2007-10-19 2:22 UTC (permalink / raw
To: gentoo-doc-cvs
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="nightmorph@gentoo.org">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>
--
gentoo-doc-cvs@gentoo.org mailing list
^ permalink raw reply [flat|nested] 3+ messages in thread
* [gentoo-doc-cvs] cvs commit: handbook-release.xml
@ 2008-04-03 23:11 Joshua Saddler
0 siblings, 0 replies; 3+ messages in thread
From: Joshua Saddler @ 2008-04-03 23:11 UTC (permalink / raw
To: gentoo-doc-cvs
nightmorph 08/04/03 23:11:34
Modified: handbook-release.xml
Log:
we're going to be doing the handbook tarballs a little differently; how catalyst expects the directory to be named and setup. per a conversation with wolf31o2 and agaffney in #gentoo-releng.
Revision Changes Path
1.2 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.2&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml?rev=1.2&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml?r1=1.1&r2=1.2
Index: handbook-release.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- handbook-release.xml 19 Oct 2007 02:22:25 -0000 1.1
+++ handbook-release.xml 3 Apr 2008 23:11:34 -0000 1.2
@@ -1,6 +1,6 @@
<?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 $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml,v 1.2 2008/04/03 23:11:34 nightmorph Exp $ -->
<guide link="/proj/en/gdp/doc/handbook-release.xml">
<title>Handbook Release Guide</title>
@@ -18,8 +18,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
-<version>1.0</version>
-<date>2007-10-18</date>
+<version>1.1</version>
+<date>2008-04-03</date>
<chapter>
<title>Introduction</title>
@@ -368,16 +368,15 @@
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.
+favorite browser and save it as <path>index.html</path>.
</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>
+$ <i>mkdir -p handbook/html/css</i>
+$ <i>cd handbook/html/</i>
<comment>(Move the HTML file here)</comment>
-$ <i>mv ../../../handbook-sparc.html ./</i>
+$ <i>mv ../../index.html ./</i>
<comment>(Download Gentoo's CSS)</comment>
$ <i>wget http://www.gentoo.org/css/main.css -O css/main.css</i>
</pre>
@@ -392,10 +391,10 @@
</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.
+Save your changes, then tar up the top-level <path>handbook</path> directory you
+created. Save it as <path>handbook-arch.tar.gz</path> (where <path>arch</path> is
+the name of the architecture), then pass it on to releng. Repeat for each
+architecture that has a networkless installation handbook.
</p>
</body>
--
gentoo-doc-cvs@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 3+ messages in thread
* [gentoo-doc-cvs] cvs commit: handbook-release.xml
@ 2008-04-23 7:09 Joshua Saddler
0 siblings, 0 replies; 3+ messages in thread
From: Joshua Saddler @ 2008-04-23 7:09 UTC (permalink / raw
To: gentoo-doc-cvs
nightmorph 08/04/23 07:09:37
Modified: handbook-release.xml
Log:
fix path, gosh darnit
Revision Changes Path
1.3 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.3&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml?rev=1.3&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml?r1=1.2&r2=1.3
Index: handbook-release.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- handbook-release.xml 3 Apr 2008 23:11:34 -0000 1.2
+++ handbook-release.xml 23 Apr 2008 07:09:37 -0000 1.3
@@ -1,6 +1,6 @@
<?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.2 2008/04/03 23:11:34 nightmorph Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gdp/doc/handbook-release.xml,v 1.3 2008/04/23 07:09:37 nightmorph Exp $ -->
<guide link="/proj/en/gdp/doc/handbook-release.xml">
<title>Handbook Release Guide</title>
@@ -18,8 +18,8 @@
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
-<version>1.1</version>
-<date>2008-04-03</date>
+<version>1.2</version>
+<date>2008-04-22</date>
<chapter>
<title>Introduction</title>
@@ -92,7 +92,7 @@
<ol>
<li>
- <uri link="doc/en/handbook/handbook-x86.xml?part=1">Installation
+ <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
--
gentoo-doc-cvs@lists.gentoo.org mailing list
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-04-23 7:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-03 23:11 [gentoo-doc-cvs] cvs commit: handbook-release.xml Joshua Saddler
-- strict thread matches above, loose matches on Subject: below --
2008-04-23 7:09 Joshua Saddler
2007-10-19 2:22 Josh Saddler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox