Attachment 208988 Details for Bug 241814 – Style revisions, accessibility enhancements, and ports statistics updates throughout the book.

[patch] Style revisions, accessibility enhancements, and ports statistics updates throughout the book.

revision-1.6.diff (text/plain), 55.63 KB, created by Pau Amma on 2019-11-08 23:21:45 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Pau Amma

Created: 2019-11-08 23:21:45 UTC

Size: 55.63 KB

patch

obsolete

>Index: en_US.ISO8859-1/books/dev-model/Makefile
>===================================================================
>--- en_US.ISO8859-1/books/dev-model/Makefile	(revision 53567)
>+++ en_US.ISO8859-1/books/dev-model/Makefile	(working copy)
>@@ -15,10 +15,6 @@
> 
> IMAGES_EN= branches.png
> IMAGES_EN+= freebsd-code-model.png
>-IMAGES_EN+= hats-overview.png
>-IMAGES_EN+= maintenance.png
>-IMAGES_EN+= orghierarchy.png
>-IMAGES_EN+= orghierarchy2.png
> IMAGES_EN+= portsstatus.png
> IMAGES_EN+= proc-add-committer.png
> IMAGES_EN+= proc-commit.png
>@@ -25,7 +21,6 @@
> IMAGES_EN+= proc-contrib.png
> IMAGES_EN+= proc-elections.png
> IMAGES_EN+= proc-pr.png
>-IMAGES_EN+= proc-releng.png
> IMAGES_EN+= proc-rm-committer.png
> 
> DOC_PREFIX?= ${.CURDIR}/../../..
>Index: en_US.ISO8859-1/books/dev-model/book.xml
>===================================================================
>--- en_US.ISO8859-1/books/dev-model/book.xml	(revision 53567)
>+++ en_US.ISO8859-1/books/dev-model/book.xml	(working copy)
>@@ -41,6 +41,12 @@
>         </copyright>
> 	<revhistory>
> 	  <revision>
>+	    <revnumber>1.6</revnumber>
>+	    <date>November, 2019</date>
>+	    <revremark>Style revisions, accessibility enhancements,
>+	      and statistics updates throughout the book.</revremark>
>+	  </revision>
>+	  <revision>
> 	    <revnumber>1.5</revnumber>
> 	    <date>October, 2014</date>
> 	    <revremark>Remove mention of GNATS which is no longer
>@@ -289,10 +295,34 @@
> 
>             </para>
>             <para>
>-                <figure>
>-                    <title>The FreeBSD Project's structure</title>
>-                    <mediaobject><imageobject><imagedata fileref="orghierarchy"/></imageobject></mediaobject>
>-                </figure>
>+                The FreeBSD Project's structure (in order of descending authority)
>+                <informaltable pgwide="1">
>+                    <tgroup cols="2">
>+                        <thead>
>+                            <row>
>+                                <entry>Group</entry>
>+                                <entry>Number of people</entry>
>+                            </row>
>+                        </thead>
>+
>+                        <tbody>
>+                            <row>
>+                                <entry>Core members</entry>
>+                                <entry>9</entry>
>+                            </row>
>+
>+                            <row>
>+                                <entry>Committers</entry>
>+                                <entry>269</entry>
>+                            </row>
>+
>+                            <row>
>+                                <entry>Contributors</entry>
>+                                <entry>~3000</entry>
>+                            </row>
>+                        </tbody>
>+                    </tgroup>
>+                </informaltable>
>             </para>
> 
>             <para>
>@@ -306,7 +336,7 @@
>                 The main resource in the FreeBSD community is its developers: the
>                 committers and contributors. It is with their contributions that the
>                 project can move forward. Regular developers are referred to as contributors.
>-                As by January 1st, 2003, there are an estimated 5500
>+                As of January 1st, 2003, there are an estimated 5500
>                 contributors on the project.
> 		
>                     </para>
>@@ -809,7 +1005,7 @@
>                         well-defined hats, and is the final arbiter of decisions involving
>                         which way the project should be heading.
> 
>-                        As by July 1st, 2004, core consisted of 9 members.
>+                        As of July 1st, 2004, core consisted of 9 members.
>                         Elections are held every two years.
>                     </para>
> 
>@@ -862,26 +1058,12 @@
>                     The official hats in the FreeBSD Project are hats that are more
>                     or less formalised and mainly administrative roles. They have
>                     the authority and responsibility for their area. The following
>-                    illustration shows the responsibility lines. After this follows
>+                    list shows the responsibility lines and gives
>                     a description of each hat, including who it is held by.
>                 </para>
> 
>-                <para>
>-                    <figure>
>-                        <title>Overview of official hats</title>
>-                        <mediaobject><imageobject><imagedata fileref="hats-overview"/></imageobject></mediaobject>
>-                    </figure>
>-                </para>
> 
>-                <para>
>-                    All boxes consist of groups of committers, except for the
>-                    dotted boxes where the holders are not necessarily committers. The
>-                    flattened circles are sub-projects and consist of both
>-                    committers and non-committers of the main project.
>-                </para>
> 
>-
>-
>                 <section xml:id="role-doc-manager" xreflabel="Documentation                     project architect">
>                     <title>Documentation project manager</title>
>                     <para>
>@@ -888,7 +1070,8 @@
>                         <xref linkend="sub-project-documentation"/>
>                         architect is responsible for
>                         defining and following up documentation goals for the
>-                        committers in the Documentation project.
>+                        committers in the Documentation project, which they
>+                        supervise.
>                     </para>
> 
>                     <para>
>@@ -904,7 +1087,7 @@
>                     <title>Postmaster</title>
>                     <para>
>                         The Postmaster is responsible for mail being correctly
>-                        delivered to the committers' email address. He is also
>+                        delivered to the committers' email address. They are also
>                         responsible for ensuring that the mailing lists work and
>                         should take measures against possible disruptions of mail
>                         such as having troll-, spam- and virus-filters.
>@@ -1014,7 +1197,7 @@
>                         The Source Repository Manager is the only one who is allowed
>                         to directly modify the repository without using the
>                         <xref linkend="tool-svn"/> tool.
>-                        It is his/her
>+                        It is their
>                         responsibility to ensure that technical problems that arise in the
>                         repository are resolved quickly. The source repository
>                         manager has the authority to back out commits if this is
>@@ -1114,7 +1297,7 @@
>                     <para>
>                         The Bugmeister is responsible for ensuring that the
>                         maintenance database is in working order, that the entries
>-                        are correctly categorised and that there are no invalid entries.
>+                        are correctly categorised and that there are no invalid entries. They supervise bugbusters.
>                     </para>
>                     <para>
>                         Hat currently held by:
>@@ -1129,13 +1312,14 @@
>                         the donations liaison officer is to match
>                         the developers with needs with people or
>                         organisations willing to make a
>-                        donation. The Donations Liaison Charter is
>-                        available
>-                        <link xlink:href="https://www.freebsd.org/donations/">here</link>
>+                        donation.
>                     </para>
>                     <para>
>                         Hat held by:
>                         the Donations Liaison Office <email>donations@FreeBSD.org</email>.
>+                        The
>+                        <link xlink:href="https://www.freebsd.org/donations/">
>+                            Donations Liaison Charter</link>.
>                     </para>
>                 </section>
> 
>@@ -1191,12 +1375,12 @@
>                 <section xml:id="role-mentor" xreflabel="Mentor">
>                     <title>Mentor</title>
>                     <para>
>-                        A mentor is a committer who takes it upon him/her to
>+                        A mentor is a committer who takes it upon them to
>                         introduce a new committer to the project, both in terms of
>-                        ensuring the new committers setup is valid,
>+                        ensuring the new committer's setup is valid,
>                         that the new committer knows the available tools required in
>-                        his/her work and that the
>-                        new committer knows what is expected of him/her in terms of
>+                        their work, and that the
>+                        new committer knows what is expected of them in terms of
>                         behavior.
>                     </para>
>                 </section>
>@@ -1260,20 +1444,20 @@
>                 </para>
> 
>                 <para>
>-                    When a contributor is given committer status, he is
>+                    When a contributor is given committer status, they are
>                     assigned a mentor. The committer who recommended the
>                     new committer will, in the general case, take it upon
>-                    himself to be the new committers mentor.
>+                    themselves to be the new committers mentor.
> 
>                 </para>
> 
>                 <para>
>-                    When a contributor is given his commit bit, a <xref linkend="tool-pgp"/>-signed email is sent
>+                    When a contributor is given their commit bit, a <xref linkend="tool-pgp"/>-signed email is sent
>                     from either <xref linkend="role-core-secretary"/>,
>-                    <xref linkend="role-ports-manager"/> or nik@freebsd.org to both
>-                    admins@freebsd.org, the assigned mentor, the new committer and
>+                    <xref linkend="role-ports-manager"/>, or nik@freebsd.org to both
>+                    admins@freebsd.org, the assigned mentor, the new committer, and
>                     core confirming the approval of a new account. The mentor then
>-                    gathers a password line, <xref linkend="tool-ssh2"/> public key and PGP key from the
>+                    gathers a password line, <xref linkend="tool-ssh2"/> public key, and PGP key from the
>                     new committer and sends them to <xref linkend="role-admin"/>. When the new account is created, the
>                     mentor activates the commit bit and guides the new committer
>                     through the rest of the initial process.
>@@ -1281,7 +1465,9 @@
> 
>                 <para>
>                     <figure>
>-                        <title>Process summary: adding a new committer</title>
>+                        <title>Process summary: adding a new committer (refer
>+                            to paragraph below for a screenreader-friendly
>+                            version)</title>
>                         <mediaobject><imageobject><imagedata fileref="proc-add-committer"/></imageobject></mediaobject>
>                     </figure>
>                 </para>
>@@ -1289,13 +1475,13 @@
>                 <para>
>                     When a contributor sends a piece of code, the receiving
>                     committer may choose to recommend that the contributor is
>-                    given commit privileges. If he recommends this to core,
>-                    they will vote on this recommendation. If they vote in
>+                    given commit privileges. If they recommend this to core,
>+                    core will vote on this recommendation. If the vote is in
>                     favour, a mentor is assigned the new committer and the new
>-                    committer has to email his details to the administrators
>+                    committer has to email their details to the administrators
>                     for an account to be created. After this, the new
>-                    committer is all set to make his first commit.  By
>-                    tradition, this is by adding his name to the committers list.
>+                    committer is all set to make their first commit.  By
>+                    tradition, this is by adding their name to the committers list.
>                 </para>
> 
>                 <para>
>@@ -1313,7 +1499,9 @@
> 
>                 <para>
>                     <figure>
>-                        <title>Process summary: removing a committer</title>
>+                        <title>Process summary: removing a committer (refer to
>+                           paragraph below for a screenreader-friendly
>+                           version)</title>
>                         <mediaobject><imageobject><imagedata fileref="proc-rm-committer"/></imageobject></mediaobject>
>                     </figure>
>                 </para>
>@@ -1322,7 +1510,8 @@
>                     When Core decides to clean up the committers list, they
>                     check who has not made a commit for the past 18 months.
>                     Committers who have not done so have their commit
>-                    bits revoked.
>+                    bits revoked and their account removed by the
>+                    administrators.
>                 </para>
> 
>                 <para>
>@@ -1370,16 +1559,16 @@
>                     frequent processes in the FreeBSD project and will usually
>                     happen many times a day. Committing of code can only be done
>                     by a <quote>committer</quote>. Committers commit either code
>-                    written by themselves, code submitted to them or code
>+                    written by themselves, code submitted to them, or code
>                     submitted through a <link linkend="model-pr">problem
>                     report</link>.
>                 </para>
> 
>                 <para>
>-                    When code is written by the developer that is non-trivial, he
>+                    When code is written by the developer that is non-trivial, they
>                     should seek a code review from the community. This
>                     is done by sending mail to the relevant list asking for
>-                    review. Before submitting the code for review, he should
>+                    review. Before submitting the code for review, they should
>                     ensure it compiles correctly with the entire tree and that all
>                     relevant tests run. This is called <quote>pre-commit
>                     test</quote>. When contributed code is received, it should be
>@@ -1409,7 +1598,7 @@
>                     set by the committer. After the number of days the
>                     committer chose when setting the MFC have passed, an email
>                     will automatically be
>-                    sent to the committer reminding him to commit it to the -STABLE
>+                    sent to the committer reminding them to commit it to the -STABLE
>                     branch (and possibly security branches as well). Only security
>                     critical changes should be merged to security branches.
>                 </para>
>@@ -1424,7 +1613,9 @@
> 
>                 <para>
>                     <figure>
>-                        <title>Process summary: A committer commits code</title>
>+                        <title>Process summary: A committer commits code (refer
>+                            to paragraph below for a screenreader-friendly
>+                            version)</title>
>                         <mediaobject><imageobject><imagedata fileref="proc-commit"/></imageobject></mediaobject>
>                     </figure>
>                 </para>
>@@ -1431,24 +1622,26 @@
> 
>                 <para>
>                     When a committer has written a piece of code and
>-                    wants to commit it, he first needs to determine if it is
>+                    wants to commit it, they first need to determine if it is
>                     trivial enough to go in without prior review or if it should
>                     first be reviewed by the developer community. If the code is
>                     trivial or has been reviewed and the committer is not the
>-                    maintainer, he should consult the maintainer before
>+                    maintainer, they should consult the maintainer before
>                     proceeding.
>                     If the code is contributed by an outside vendor, the
>                     maintainer should create a patch that is sent back to the
>-                    vendor. The code is then committed and the deployed by
>+                    vendor. The code is then committed and then deployed by
>                     the users. Should they find problems with the code, this
>                     will be reported and the committer can go back to writing
>-                    a patch. If a vendor is affected, he can choose to
>+                    a patch. If a vendor is affected, they can choose to
>                     implement or ignore the patch.
>                 </para>
> 
>                 <para>
>                     <figure>
>-                        <title>Process summary: A contributor commits code</title>
>+                        <title>Process summary: A contributor commits code
>+                            (refer to paragraphs below and above for a
>+                            screenreader-friendly version)</title>
>                         <mediaobject><imageobject><imagedata fileref="proc-contrib"/></imageobject></mediaobject>
>                     </figure>
>                 </para>
>@@ -1455,7 +1648,7 @@
> 
>                 <para>
>                     The difference when a contributor makes a code contribution is
>-                    that he submits the code through the Bugzilla
>+                    that they submit the code through the Bugzilla
>                     interface. This report is picked up by the maintainer who
>                     reviews the code and commits it.
>                 </para>
>@@ -1547,7 +1740,9 @@
> 
>                 <para>
>                     <figure>
>-                        <title>Process summary: Core elections</title>
>+                        <title>Process summary: Core elections (refer to
>+                           paragraph below for a screenreader-friendly
>+                           version)</title>
>                         <mediaobject><imageobject><imagedata fileref="proc-elections"/></imageobject></mediaobject>
>                     </figure>
>                 </para>
>@@ -1554,7 +1749,7 @@
> 
>                 <para>
>                     Core announces the election and selects an election
>-                    manager. He prepares the elections, and when ready,
>+                    manager who prepares the elections, and when ready,
>                     candidates can announce their candidacies through
>                     submitting their statements. The committers then vote.
>                     After the vote is over, the election results are
>@@ -1607,8 +1802,8 @@
>                     requests by mail, Problem Reports, commercial funding for the development
>                     of features, or contributions by the scientific community.
>                     The wishes that come within the responsibility of a developer
>-                    are given to that developer who prioritises his time between
>-                    the request and his wishes. A common way to do this is maintain
>+                    are given to that developer who prioritises their time between
>+                    the request and their wishes. A common way to do this is maintain
>                     a TODO-list maintained by the project. Items that do not come within
>                     someone's responsibility are collected on TODO-lists unless someone
>                     volunteers to take the responsibility. All
>@@ -1629,7 +1824,7 @@
> 
>                 <para>
>                     As the requests are prioritised by the individual developers on
>-                    the basis of doing what they find interesting, necessary or are
>+                    the basis of doing what they find interesting, necessary, or are
>                     funded to do, there is no overall strategy or prioritisation of
>                     what requests to regard as requirements and following up their
>                     correct implementation. However, most developers have some
>@@ -1707,10 +1902,55 @@
>                 </para>
> 
>                 <para>
>-                    <figure>
>-                        <title>J&oslash;rgenssen's model for change integration</title>
>-                        <mediaobject><imageobject><imagedata fileref="maintenance"/></imageobject></mediaobject>
>-                    </figure>
>+                    J&oslash;rgenssen's model for change integration
>+                    <informaltable pgwide="1">
>+                        <tgroup cols="3">
>+                            <thead>
>+                                <row>
>+                                    <entry>Stage</entry>
>+                                    <entry>Next if successful</entry>
>+                                    <entry>Next if unsuccessful</entry>
>+                                </row>
>+                            </thead>
>+                            <tbody>
>+                                <row>
>+                                    <entry>code</entry>
>+                                    <entry>review</entry>
>+                                    <entry></entry>
>+                                </row>
>+
>+                                <row>
>+                                    <entry>review</entry>
>+                                    <entry>pre-commit test</entry>
>+                                    <entry>code</entry>
>+                                </row>
>+
>+                                <row>
>+                                    <entry>pre-commit test</entry>
>+                                    <entry>development release</entry>
>+                                    <entry>code</entry>
>+                                </row>
>+
>+                                <row>
>+                                    <entry>development release</entry>
>+                                    <entry>parallel debugging</entry>
>+                                    <entry>code</entry>
>+                                </row>
>+
>+                                <row>
>+                                    <entry>parallel debugging</entry>
>+                                    <entry>production release</entry>
>+                                    <entry>code</entry>
>+                                </row>
>+
>+                                <row>
>+                                    <entry>production release</entry>
>+                                    <entry></entry>
>+                                    <entry>code</entry>
>+                                </row>
>+                            </tbody>
>+                        </tgroup>
>+                    </informaltable>
>                 </para>
> 
>                 <para>
>@@ -1788,7 +2028,9 @@
> 
>                 <para>
>                     <figure>
>-                        <title>Process summary: problem reporting</title>
>+                        <title>Process summary: problem reporting (refer to
>+                            paragraph below for a screenreader-friendly
>+                            version)</title>
>                         <mediaobject><imageobject><imagedata fileref="proc-pr"/></imageobject></mediaobject>
>                     </figure>
>                 </para>
>@@ -1796,8 +2038,8 @@
>                 <para>
>                     A problem is reported by the report originator. It is
>                     then classified by a bugbuster and handed to the correct
>-                    maintainer. He verifies the problem and discusses the
>-                    problem with the originator until he has enough
>+                    maintainer. They verify the problem and discuss the
>+                    problem with the originator until they have enough
>                     information to create a working patch. This patch is then
>                     committed and the problem report is closed.
>                 </para>
>@@ -1833,7 +2075,7 @@
>                     number of rules that committers should follow. However, it
>                     happens that these rules are broken. The following rules exist
>                     in order to be able to react to misbehavior. They specify what
>-                    actions will result in how long a suspension the committer's
>+                    actions will result in how long a suspension of the committer's
>                     commit privileges.
> 
>                     <itemizedlist>
>@@ -1861,7 +2103,7 @@
>                     mailing list. Repeat offenders can, with a 2/3 vote by core,
>                     receive harsher penalties, including permanent removal of
>                     commit privileges. (However, the latter is always viewed as a last
>-                    resort, due to its inherent tendency to create controversy).  All
>+                    resort, due to its inherent tendency to create controversy.)  All
>                     suspensions are posted to the
>                     <quote>developers</quote>
>                     mailing list, a list available to committers only.
>@@ -1912,10 +2154,10 @@
>                     be committed to the branch without the release engineers'
>                     explicit consent. Code-freeze means no changes to the code (like
>                     bugs-fixes) are allowed to be committed without the release
>-                    engineers explicit consent. This feature- and code-freeze is
>+                    engineers' explicit consent. This feature- and code-freeze is
>                     known as stabilising. During the release process, the release
>                     engineer has the full authority to revert to older versions of
>-                    code and thus "back out" changes should he find that the changes
>+                    code and thus "back out" changes should they find that the changes
>                     are not suitable to be included in the release.
>                 </para>
> 
>@@ -1962,7 +2204,7 @@
>                     releases are considered release candidates. At the end of the
>                     release process, a release is created with the new version
>                     number, including binary distributions on web sites and the
>-                    creation of a CD-ROM images.  However, the release is not
>+                    creation of CD-ROM images.  However, the release is not
>                     considered "really released" until a <xref linkend="tool-pgp"/>-signed message stating
>                     exactly that, is sent to the mailing list freebsd-announce; anything
>                     labelled as a "release" before that may well be in-process and
>@@ -2024,19 +2266,24 @@
> 
> 
>                 <para>
>-                    <figure>
>-                        <title>Process summary: release engineering</title>
>-                        <mediaobject><imageobject><imagedata fileref="proc-releng"/></imageobject></mediaobject>
>-                    </figure>
>+                    <orderedlist>
>+                        <listitem><para>Make release schedule</para></listitem>
>+                        <listitem><para>Feature freeze</para></listitem>
>+                        <listitem><para>Code freeze</para></listitem>
>+                        <listitem><para>Make branch</para></listitem>
>+                        <listitem><para>Release candidate</para></listitem>
>+                        <listitem><para>Stabilize release (loop back to
>+                            previous step as many times as necessary; when
>+                            release is considered stable, proceed with next
>+                            step)
>+                        </para></listitem>
>+                        <listitem><para>Build packages</para></listitem>
>+                        <listitem><para>Warn mirrors</para></listitem>
>+                        <listitem><para>Publish release</para></listitem>
>+                    </orderedlist>
>                 </para>
> 
>-                <para>
>-                    These are the stages in the release engineering
>-                    process. Multiple release candidates may be created until
>-                    the release is deemed stable enough to be released.
>-                </para>
> 
>-
>                 <para>
>                     <citation><xref linkend="freebsd-releng"/></citation>
>                 </para>
>@@ -2077,7 +2324,7 @@
>                     and editing bug reports. The project uses its
>                     web interface to send
>                     <quote>Problem Reports</quote> to the
>-                    projects central Bugzilla server. The committers also have web and
>+                    project's central Bugzilla server. The committers also have web and
>                     command-line clients.
>                 </para>
>             </section>
>@@ -2088,7 +2335,7 @@
>                     Mailman is a program that automates the
>                     management of mailing lists. The FreeBSD Project uses it to run
>                     16 general lists, 60 technical lists, 4 limited lists and 5 lists
>-		    with CVS commit logs. It is
>+		    with SVN commit logs. It is
>                     also used for many mailing lists set up and used by other people
>                     and projects in the FreeBSD community. General lists are lists
>                     for the general public, technical lists are mainly for the
>@@ -2108,7 +2355,7 @@
>                     using a public key architecture to allow people to digitally
>                     sign and/or encrypt information in order to ensure secure
>                     communication between two parties. A signature is used when
>-                    sending information out many recipients, enabling them to verify
>+                    sending information out to many recipients, enabling them to verify
>                     that the information has not been tampered with before they
>                     received it. In the FreeBSD Project this is the primary means of
>                     ensuring that information has been written by the person who
>@@ -2152,25 +2399,182 @@
>                 <para>
>                     A <quote>port</quote> is a set of meta-data and patches that
>                     are needed to fetch, compile and install correctly an external piece of
>-                    software on a FreeBSD system. The amount of ports have grown
>+                    software on a FreeBSD system. The amount of ports has grown
>                     at a tremendous rate, as shown by the following figure.
>                 </para>
> 
>                 <para>
>                     <figure xml:id="fig-ports">
>-                        <title>Number of ports added between 1996 and 2005</title>
>+                        <title>Number of ports added between 1996 and 2008
>+                            (refer to tables below for a screenreader-friendly
>+                            version)</title>
>                         <mediaobject><imageobject><imagedata fileref="portsstatus"/></imageobject></mediaobject>
>                     </figure>
>                 </para>
> 
>                 <para>
>-                    <xref linkend="fig-ports"/> is taken from
>-                    <link xlink:href="https://www.freebsd.org/ports/growth/status.png">
>-                    the FreeBSD web site</link>. It shows the number of ports
>-                    available to FreeBSD in the period 1995 to 2005. It looks
>-                    like the curve has first grown exponentionally, and then
>-                    since the middle of 2001 grown linearly.
>+                    <xref linkend="fig-ports"/>
>+                    shows the number of ports
>+                    available to FreeBSD in the period 1995 to 2008. It looks
>+                    like the curve has first grown exponentially, and then
>+                    from the middle of 2001 to the middle of 2007 grown
>+                    linearly at a rate of about 2000 ports/year, before its
>+                    growth rate gets lower.
>                 </para>
>+                <para>
>+                    Approximate dates each multiple of 1000 ports is reached
>+                    <informaltable pgwide="1">
>+                        <tgroup cols="2">
>+                            <thead>
>+                                <row>
>+                                    <entry>Number of ports</entry>
>+                                    <entry>Approximate date</entry>
>+                                </row>
>+                            </thead>
>+                            <tbody>
>+                                <row>
>+                                    <entry>1000</entry>
>+                                    <entry>Late 1997</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2000</entry>
>+                                    <entry>Late 1998</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>3000</entry>
>+                                    <entry>Early 2000</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>4000</entry>
>+                                    <entry>Late 2000</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>5000</entry>
>+                                    <entry>Mid 2001</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>6000</entry>
>+                                    <entry>4th quarter of 2001</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>7000</entry>
>+                                    <entry>Mid 2002</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>8000</entry>
>+                                    <entry>4th quarter of 2002</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>9000</entry>
>+                                    <entry>Mid 2003</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>10000</entry>
>+                                    <entry>End of 2003</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>11000</entry>
>+                                    <entry>Mid 2004</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>12000</entry>
>+                                    <entry>End of 2004</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>13000</entry>
>+                                    <entry>Mid 2005</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>14000</entry>
>+                                    <entry>Early 2006</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>15000</entry>
>+                                    <entry>Mid 2006</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>16000</entry>
>+                                    <entry>3rd quarter 2006</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>17000</entry>
>+                                    <entry>2nd quarter 2007</entry>
>+                                </row>
>+                            </tbody>
>+                        </tgroup>
>+                    </informaltable>
>+                </para>
>+                <para>
>+                    Approximate number of ports at the start of each year
>+                    <informaltable pgwide="1">
>+                        <tgroup cols="2">
>+                            <thead>
>+                                <row>
>+                                    <entry>Year</entry>
>+                                    <entry>Approximate number of ports</entry>
>+                                </row>
>+                            </thead>
>+                            <tbody>
>+                                <row>
>+                                    <entry>1995</entry>
>+                                    <entry>100</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>1996</entry>
>+                                    <entry>300</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>1997</entry>
>+                                    <entry>700</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>1998</entry>
>+                                    <entry>1200</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>1999</entry>
>+                                    <entry>2000</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2000</entry>
>+                                    <entry>2900</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2001</entry>
>+                                    <entry>4300</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2002</entry>
>+                                    <entry>6200</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2003</entry>
>+                                    <entry>8100</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2004</entry>
>+                                    <entry>10050</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2005</entry>
>+                                    <entry>12100</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2006</entry>
>+                                    <entry>14000</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2007</entry>
>+                                    <entry>16200</entry>
>+                                </row>
>+                                <row>
>+                                    <entry>2008</entry>
>+                                    <entry>17900</entry>
>+                                </row>
>+                            </tbody>
>+                        </tgroup>
>+                    </informaltable>
>+                </para>
> 
>                 <para>
>                     As the external software described by the port often is under
>@@ -2256,9 +2660,9 @@
>                 </para>
> 
>                 <para>
>-                    The Documentation project has a primer. This is used both to
>+                    The Documentation project has <link xlink:href="https://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/">a primer</link>. This is used both to
>                     introduce new project members to the standard tools and
>-                    syntaxes and acts as a reference when working on the project.
>+                    syntaxes and to act as a reference when working on the project.
>                 </para>
> 
>             </section>
>Index: share/images/books/dev-model/portsstatus.png
>===================================================================
>Cannot display: file marked as a binary type.
>svn:mime-type = image/png

Actions: View | Diff

Attachments on bug 241814: 208988 | 208989