From owner-svn-doc-head@freebsd.org Tue Mar 31 22:45:06 2020 Return-Path: Delivered-To: svn-doc-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2CECF26F171; Tue, 31 Mar 2020 22:45:06 +0000 (UTC) (envelope-from brooks@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48sPXw6SYkz3LBP; Tue, 31 Mar 2020 22:45:04 +0000 (UTC) (envelope-from brooks@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 71F7B19FED; Tue, 31 Mar 2020 22:44:56 +0000 (UTC) (envelope-from brooks@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id 02VMitLk051886; Tue, 31 Mar 2020 22:44:55 GMT (envelope-from brooks@FreeBSD.org) Received: (from brooks@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 02VMitnR051885; Tue, 31 Mar 2020 22:44:55 GMT (envelope-from brooks@FreeBSD.org) Message-Id: <202003312244.02VMitnR051885@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: brooks set sender to brooks@FreeBSD.org using -f From: Brooks Davis Date: Tue, 31 Mar 2020 22:44:55 +0000 (UTC) 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 X-SVN-Group: doc-head X-SVN-Commit-Author: brooks X-SVN-Commit-Paths: head/en_US.ISO8859-1/articles/committers-guide X-SVN-Commit-Revision: 54028 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 22:45:06 -0000 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 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) 2048 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 cost associated with additional platform support. 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. + 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. Platform Targets 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. + 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. 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. + 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. 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 native ABI as - the default ABI. The native ABI generally - shares certain properties with the kernel ABI such as the C - calling convention, sizes of basic types, etc. + 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 native ABI as + the default ABI. The native ABI generally + shares certain properties with the kernel ABI such as the C + calling convention, sizes of basic types, etc. 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. + the common case, a platform's kernel and &os; ABIs are + assigned to the same tier. Tier 1: Fully-Supported Architectures 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. + 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. The &os; Project provides the following guarantees to - consumers of Tier 1 platforms: + consumers of Tier 1 platforms: @@ -4142,8 +4142,8 @@ Relnotes: yes To maintain maturity of Tier 1 platforms, the &os; Project - will maintain the following resources to support - development: + will maintain the following resources to support + development: @@ -4165,7 +4165,7 @@ Relnotes: yes Collectively, developers are required to provide the - following to maintain the Tier 1 status of a platform: + following to maintain the Tier 1 status of a platform: @@ -4203,18 +4203,18 @@ Relnotes: yes Tier 2: Developmental and Niche Architectures Tier 2 platforms are functional, but less mature &os; - platforms. They are not supported by the security officer, - release engineering, and port management teams. + platforms. They are not supported by the security officer, + release engineering, and port management teams. 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. + 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. The &os; Project provides the following guarantees to - consumers of Tier 2 platforms: + consumers of Tier 2 platforms: @@ -4248,8 +4248,8 @@ Relnotes: yes To maintain maturity of Tier 2 platforms, the &os; Project - will maintain the following resources to support - development: + will maintain the following resources to support + development: @@ -4259,7 +4259,7 @@ Relnotes: yes Collectively, developers are required to provide the - following to maintain the Tier 2 status of a platform: + following to maintain the Tier 2 status of a platform: @@ -4288,22 +4288,22 @@ Relnotes: yes Tier 3: Experimental Architectures Tier 3 platforms have at least partial &os; support. They - are not supported by the security - officer, release engineering, and port management - teams. + are not supported by the security + officer, release engineering, and port management + teams. 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. + 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. 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. + 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. @@ -4313,21 +4313,21 @@ Relnotes: yes project. 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. + 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. Policy on Changing the Tier of an Architecture 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. + 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. @@ -5375,7 +5375,8 @@ Do you want to commit? (no = start a shell) [y/n] - &a.portmgr; will reply with a possible fallout. + &a.portmgr; will reply with a possible + fallout.