Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 31 Mar 2020 22:44:55 +0000 (UTC)
From:      Brooks Davis <brooks@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r54028 - head/en_US.ISO8859-1/articles/committers-guide
Message-ID:  <202003312244.02VMitnR051885@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: brooks (src,ports committer)
Date: Tue Mar 31 22:44:55 2020
New Revision: 54028
URL: https://svnweb.freebsd.org/changeset/doc/54028

Log:
  Passify igor: use tabs not spaces, wrap one line.
  
  It's now feasible to use igor to spellcheck this document.  There are
  still a few reported issues, but I belive they are false positives due
  to nested <step>s.

Modified:
  head/en_US.ISO8859-1/articles/committers-guide/article.xml

Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml	Tue Mar 31 21:22:23 2020	(r54027)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml	Tue Mar 31 22:44:55 2020	(r54028)
@@ -265,7 +265,7 @@ RSA keys may be between 1024 and 4096 bits long.
 What keysize do you want? (2048) <userinput>2048</userinput>  <co xml:id="co-pgp-bits"/>
 Requested keysize is 2048 bits
 Please specify how long the key should be valid.
-         0 = key does not expire
+	 0 = key does not expire
       &lt;n&gt;  = key expires in n days
       &lt;n&gt;w = key expires in n weeks
       &lt;n&gt;m = key expires in n months
@@ -4007,66 +4007,66 @@ Relnotes:           yes</programlisting>
 	cost associated with additional platform support.</para>
 
       <para>The &os; Project differentiates platform targets into four
-        tiers.  Each tier includes a list of guarantees consumers may
-        rely on as well as obligations by the Project and developers
-        to fulfill those guarantees.  These lists define the minimum
-        guarantees for each tier.  The Project and developers may
-        provide additional levels of support beyond the minimum
-        guarantees for a given tier, but such additional support is
-        not guaranteed.  Each platform target is assigned to a
-        specific tier for each stable branch.  As a result, a platform
-        target might be assigned to different tiers on concurrent
-        stable branches.</para>
+	tiers.  Each tier includes a list of guarantees consumers may
+	rely on as well as obligations by the Project and developers
+	to fulfill those guarantees.  These lists define the minimum
+	guarantees for each tier.  The Project and developers may
+	provide additional levels of support beyond the minimum
+	guarantees for a given tier, but such additional support is
+	not guaranteed.  Each platform target is assigned to a
+	specific tier for each stable branch.  As a result, a platform
+	target might be assigned to different tiers on concurrent
+	stable branches.</para>
     </sect2>
 
     <sect2>
       <title>Platform Targets</title>
 
       <para>Support for a hardware platform consists of two
-        components: kernel support and userland Application Binary
-        Interfaces (ABIs).  Kernel platform support includes things
-        needed to run a &os; kernel on a hardware platform such as
-        machine-dependent virtual memory management and device
-        drivers.  A userland ABI specifies an interface for user
-        processes to interact with a &os; kernel and base system
-        libraries.  A userland ABI includes system call interfaces,
-        the layout and semantics of public data structures, and the
-        layout and semantics of arguments passed to subroutines.  Some
-        components of an ABI may be defined by specifications such as
-        the layout of C++ exception objects or calling conventions for
-        C functions.</para>
+	components: kernel support and userland Application Binary
+	Interfaces (ABIs).  Kernel platform support includes things
+	needed to run a &os; kernel on a hardware platform such as
+	machine-dependent virtual memory management and device
+	drivers.  A userland ABI specifies an interface for user
+	processes to interact with a &os; kernel and base system
+	libraries.  A userland ABI includes system call interfaces,
+	the layout and semantics of public data structures, and the
+	layout and semantics of arguments passed to subroutines.  Some
+	components of an ABI may be defined by specifications such as
+	the layout of C++ exception objects or calling conventions for
+	C functions.</para>
 
       <para>A &os; kernel also uses an ABI (sometimes referred to as
-        the Kernel Binary Interface (KBI)) which includes the
-        semantics and layouts of public data structures and the layout
-        and semantics of arguments to public functions within the
-        kernel itself.</para>
+	the Kernel Binary Interface (KBI)) which includes the
+	semantics and layouts of public data structures and the layout
+	and semantics of arguments to public functions within the
+	kernel itself.</para>
 
       <para>A &os; kernel may support multiple userland ABIs.  For
-        example, &os;'s amd64 kernel supports &os; amd64 and i386
-        userland ABIs as well as Linux x86_64 and i386 userland ABIs.
-        A &os; kernel should support a <quote>native</quote> ABI as
-        the default ABI.  The native <quote>ABI</quote> generally
-        shares certain properties with the kernel ABI such as the C
-        calling convention, sizes of basic types, etc.</para>
+	example, &os;'s amd64 kernel supports &os; amd64 and i386
+	userland ABIs as well as Linux x86_64 and i386 userland ABIs.
+	A &os; kernel should support a <quote>native</quote> ABI as
+	the default ABI.  The native <quote>ABI</quote> generally
+	shares certain properties with the kernel ABI such as the C
+	calling convention, sizes of basic types, etc.</para>
 
       <para>Tiers are defined for both kernels and userland ABIs.  In
-        the common case, a platform's kernel and &os; ABIs are
-        assigned to the same tier.</para>
+	the common case, a platform's kernel and &os; ABIs are
+	assigned to the same tier.</para>
     </sect2>
 
     <sect2>
       <title>Tier 1: Fully-Supported Architectures</title>
 
       <para>Tier 1 platforms are the most mature &os; platforms.
-        They are supported by the security officer, release
-        engineering, and port management teams.  Tier 1 architectures
-        are expected to be Production Quality with respect to all
-        aspects of the &os; operating system, including installation
-        and development environments.</para>
+	They are supported by the security officer, release
+	engineering, and port management teams.  Tier 1 architectures
+	are expected to be Production Quality with respect to all
+	aspects of the &os; operating system, including installation
+	and development environments.</para>
 
       <para>The &os; Project provides the following guarantees to
-        consumers of Tier 1 platforms:</para>
+	consumers of Tier 1 platforms:</para>
 
       <itemizedlist>
 	<listitem>
@@ -4142,8 +4142,8 @@ Relnotes:           yes</programlisting>
       </itemizedlist>
 
       <para>To maintain maturity of Tier 1 platforms, the &os; Project
-        will maintain the following resources to support
-        development:</para>
+	will maintain the following resources to support
+	development:</para>
 
       <itemizedlist>
 	<listitem>
@@ -4165,7 +4165,7 @@ Relnotes:           yes</programlisting>
       </itemizedlist>
 
       <para>Collectively, developers are required to provide the
-        following to maintain the Tier 1 status of a platform:</para>
+	following to maintain the Tier 1 status of a platform:</para>
 
       <itemizedlist>
 	<listitem>
@@ -4203,18 +4203,18 @@ Relnotes:           yes</programlisting>
       <title>Tier 2: Developmental and Niche Architectures</title>
 
       <para>Tier 2 platforms are functional, but less mature &os;
-        platforms.  They are not supported by the security officer,
-        release engineering, and port management teams.</para>
+	platforms.  They are not supported by the security officer,
+	release engineering, and port management teams.</para>
 
       <para>Tier 2 platforms may be Tier 1 platform candidates that
-        are still under active development.  Architectures reaching
-        end of life may also be moved from Tier 1 status to Tier 2
-        status as the availability of resources to continue to
-        maintain the system in a Production Quality state diminishes.
-        Well-supported niche architectures may also be Tier 2.</para>
+	are still under active development.  Architectures reaching
+	end of life may also be moved from Tier 1 status to Tier 2
+	status as the availability of resources to continue to
+	maintain the system in a Production Quality state diminishes.
+	Well-supported niche architectures may also be Tier 2.</para>
 
       <para>The &os; Project provides the following guarantees to
-        consumers of Tier 2 platforms:</para>
+	consumers of Tier 2 platforms:</para>
 
       <itemizedlist>
 	<listitem>
@@ -4248,8 +4248,8 @@ Relnotes:           yes</programlisting>
       </itemizedlist>
 
       <para>To maintain maturity of Tier 2 platforms, the &os; Project
-        will maintain the following resources to support
-        development:</para>
+	will maintain the following resources to support
+	development:</para>
 
       <itemizedlist>
 	<listitem>
@@ -4259,7 +4259,7 @@ Relnotes:           yes</programlisting>
       </itemizedlist>
 
       <para>Collectively, developers are required to provide the
-        following to maintain the Tier 2 status of a platform:</para>
+	following to maintain the Tier 2 status of a platform:</para>
 
       <itemizedlist>
 	<listitem>
@@ -4288,22 +4288,22 @@ Relnotes:           yes</programlisting>
       <title>Tier 3: Experimental Architectures</title>
 
       <para>Tier 3 platforms have at least partial &os; support.  They
-        are <emphasis>not</emphasis> supported by the security
-        officer, release engineering, and port management
-        teams.</para>
+	are <emphasis>not</emphasis> supported by the security
+	officer, release engineering, and port management
+	teams.</para>
 
       <para>Tier 3 platforms are architectures in the early stages of
-        development, for non-mainstream hardware platforms, or which
-        are considered legacy systems unlikely to see broad future
-        use.  Initial support for Tier 3 platforms may exist in a
-        separate repository rather than the main source
-        repository.</para>
+	development, for non-mainstream hardware platforms, or which
+	are considered legacy systems unlikely to see broad future
+	use.  Initial support for Tier 3 platforms may exist in a
+	separate repository rather than the main source
+	repository.</para>
 
       <para>The &os; Project provides no guarantees to consumers of
-        Tier 3 platforms and is not committed to maintaining resources
-        to support development.  Tier 3 platforms may not always be
-        buildable, nor are any kernel or userland ABIs considered
-        stable.</para>
+	Tier 3 platforms and is not committed to maintaining resources
+	to support development.  Tier 3 platforms may not always be
+	buildable, nor are any kernel or userland ABIs considered
+	stable.</para>
     </sect2>
 
     <sect2>
@@ -4313,21 +4313,21 @@ Relnotes:           yes</programlisting>
 	project.</para>
 
       <para>All systems not otherwise classified are Tier 4 systems.
-        When a platform transitions to Tier 4, all support for the
-        platform is removed from the source and ports trees.  Note
-        that ports support should remain as long as the platform is
-        supported in a branch supported by ports.</para>
+	When a platform transitions to Tier 4, all support for the
+	platform is removed from the source and ports trees.  Note
+	that ports support should remain as long as the platform is
+	supported in a branch supported by ports.</para>
     </sect2>
 
     <sect2>
       <title>Policy on Changing the Tier of an Architecture</title>
 
       <para>Systems may only be moved from one tier to another by
-        approval of the &os; Core Team, which shall make that decision
-        in collaboration with the Security Officer, Release
-        Engineering, and ports management teams.  For a platform to be
-        promoted to a higher tier, any missing support guarantees must
-        be satisfied before the promotion is completed.</para>
+	approval of the &os; Core Team, which shall make that decision
+	in collaboration with the Security Officer, Release
+	Engineering, and ports management teams.  For a platform to be
+	promoted to a higher tier, any missing support guarantees must
+	be satisfied before the promotion is completed.</para>
     </sect2>
   </sect1>
 
@@ -5375,7 +5375,8 @@ Do you want to commit? (no = start a shell) [y/n]</scr
 	      </step>
 
 	      <step>
-                <para>&a.portmgr; will reply with a possible fallout.</para>
+		<para>&a.portmgr; will reply with a possible
+		  fallout.</para>
 	      </step>
 
 	      <step>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202003312244.02VMitnR051885>