os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Passify igor: use tabs not spaces, wrap one line.

Browse source 
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.
This commit is contained in:
Brooks Davis 2020-03-31 22:44:55 +00:00
parent a26f7a45c5
commit d7ece367ac
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=54028
1 changed files with 78 additions and 77 deletions

155
en_US.ISO8859-1/articles/committers-guide/article.xml
View file

@ -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]</screen>
</step>
<step>
<para>&a.portmgr; will reply with a possible fallout.</para>
<para>&a.portmgr; will reply with a possible
fallout.</para>
</step>
<step>