svn commit: r54028 - head/en_US.ISO8859-1/articles/committers-guide
Brooks Davis <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
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
<n> = key expires in n days
<n>w = key expires in n weeks
<n>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>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"