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