TCP Wrappers

対応していないプラットフォーム

FreeBSD 10 までは Tier 2。それ以降はサポートされません。

FreeBSD 12 から Tier 3

Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BC1ED276A4; Fri, 31 Mar 2017 15:15:52 +0000 (UTC) (envelope-from mat@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 mx1.freebsd.org (Postfix) with ESMTPS id B9188E7B; Fri, 31 Mar 2017 15:15:51 +0000 (UTC) (envelope-from mat@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v2VFFoFF011257; Fri, 31 Mar 2017 15:15:50 GMT (envelope-from mat@FreeBSD.org) Received: (from mat@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v2VFFoX4011256; Fri, 31 Mar 2017 15:15:50 GMT (envelope-from mat@FreeBSD.org) Message-Id: <201703311515.v2VFFoX4011256@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: mat set sender to mat@FreeBSD.org using -f From: Mathieu Arnold Date: Fri, 31 Mar 2017 15:15:50 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r50114 - head/en_US.ISO8859-1/books/porters-handbook/makefiles X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire doc trees $except for " user" , " projects" , and " translations" $" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:15:52 -0000 Author: mat Date: Fri Mar 31 15:15:50 2017 New Revision: 50114 URL: https://svnweb.freebsd.org/changeset/doc/50114 Log: Remove ALWAYS_KEEP_DISTFILES, it is not used by anything. Sponsored by: Absolight Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Thu Mar 30 23:06:52 2017 (r50113) +++ head/en_US.ISO8859-1/books/porters-handbook/makefiles/chapter.xml Fri Mar 31 15:15:50 2017 (r50114) @@ -3145,39 +3145,6 @@ PATCHFILES= patch1:test Makefile.

- &os; Release Engineering + + &os; Release Engineering &tm-attrib.freebsd; @@ -32,30 +50,30 @@ Development of &os; has a very specific workflow. In general, all changes to the &os; base system are committed to - the head/ branch, which reflects the top of - the source tree. + the &branch.head; branch, which reflects the top of the source + tree. After a reasonable testing period, changes can then be - merged to the stable/ branches. The default - minimum timeframe before merging to stable/ - branches is three (3) days. + merged to the &branch.stable; branches. The default minimum + timeframe before merging to &branch.stable; branches is three + (3) days. Although a general rule to wait a minimum of three days - before mergeing from head/, there are a few - special circumstances where an immediate merge may be necessary, - such as a critical security fix, or a bug fix that directly - inhibits the release build process. + before merging from &branch.head;, there are a few special + circumstances where an immediate merge may be necessary, such as + a critical security fix, or a bug fix that directly inhibits the + release build process. After several months, and the number of changes in the - stable/ branch have grown significantly, it - is time to release the next version of &os;. These releases - have been historically referred to as point + &branch.stable; branch have grown significantly, it is time to + release the next version of &os;. These releases have been + historically referred to as point releases. - In between releases from the stable/ - branches, approximately every two (2) years, a release will be - cut directly from head/. These releases - have been historically referred to as dot-zero + In between releases from the &branch.stable; branches, + approximately every two (2) years, a release will be cut + directly from &branch.head;. These releases have been + historically referred to as dot-zero releases. This article will highlight the workflow and @@ -76,6 +94,16 @@ + + + + Terminology and general information, such as the + code slush and code + freeze, used throughout this document. + + + + @@ -92,6 +120,31 @@ point release. + + + + + + Information related to the specific procedures to + build installation medium. + + + + + + + + Procedures to publish installation medium. + + + + + + + + Wrapping up the release cycle. + + @@ -115,75 +168,248 @@ - head/ slush: - August 24 + &branch.head; slush: + May 27, 2016 + + + + &branch.head; freeze: + June 10, 2016 - head/ freeze: - September 7 + &branch.head; KBI freeze: + June 24, 2016 - head/ KBI freeze: - September 21 + doc/ tree slush [1]: + June 24, 2016 - stable/10/ - branch: - October 10 + Ports quarterly branch [2]: + July 1, 2016 + + + + &branch.stablex; branch: + July 8, 2016 + + + + doc/ tree tag [3]: + July 8, 2016 BETA1 build starts: - October 12 + July 8, 2016 + + + + &branch.head; thaw: + July 9, 2016 BETA2 build starts: - October 18 + July 15, 2016 + + + + BETA3 build starts [*]: + July 22, 2016 - releng/10.0/ - branch: - November 1 + &branch.relengx; branch: + July 29, 2016 RC1 build starts: - November 1 + July 29, 2016 + + + + &branch.stablex; thaw: + July 30, 2016 RC2 build starts: - November 9 + August 5, 2016 + + + + Final Ports package builds [4]: + August 6, 2016 + + + + Ports release tag: + August 12, 2016 + + + + RC3 build starts [*]: + August 12, 2016 RELEASE build starts: - November 19 + August 19, 2016 + + + + RELEASE announcement: + September 2, 2016 - After general agreement on the schedule, the &team.re; - emails the the schedule to the &os; Developers. - - - - Release from <literal>head/</literal> + + Items marked with "[*]" are "as + needed". + + + + + The doc/ tree slush is coordinated by + the &team.doceng;. + + + + The Ports quarterly branch used is determined by when + the final RC build is planned. A new + quarterly branch is created on the first day of the quarter, + so this metric should be used when taking the release cycle + milestones into account. The quarterly branch is created by + the &team.portmgr;. + + + + The doc/ tree is tagged by the + &team.doceng;. + + + + The final Ports package build is done by the + &team.portmgr; after the final (or what is expected to be + final) RC build. + + + + + If the release is being created from an existing + &branch.stable; branch, the KBI + freeze date can be excluded, since the KBI + is already considered frozen on established + &branch.stable; branches. + + + When writing the release cycle schedule, a number of things + need to be taken into consideration, in particular milestones + where the target date depends on predefined milestones upon + which there is a dependency. For example, the Ports Collection + release tag originates from the active quarterly branch at the + time of the last RC. This in part defines + which quarterly branch is used, when the release tag can happen, + and what revision of the ports tree is used for the final + RELEASE build. - + After general agreement on the schedule, the &team.re; + emails the schedule to the &os; Developers. + It is somewhat typical that many developers will inform + the &team.re; about various works-in-progress. In some cases, + an extension for the in-progress work will be requested, and + in other cases, a request for blanket approval + to a particular subset of the tree will be made. + + When such requests are made, it is important to make sure + timelines (even if estimated) are discussed. For blanket + approvals, the length of time for the blanket approval should + be made clear. For example, a &os; developer may request + blanket approvals from the start of the code slush until the + start of the RC builds. + + Depending on the underlying set of code in question, and + the overall impact the set of code has on &os; as a whole, such + requests may be approved or denied by the &team.re;. + + The same applies to work-in-progress extensions. For + example, in-progress work for a new device driver that is + otherwise isolated from the rest of the tree may be granted + an extension. A new scheduler, however, may not be feasible, + especially if such dramatic changes do not exist in another + branch. + + The schedule is also added to the Project website, in the + doc/ repository, in + head/en_US.ISO8859-1/htdocs/releases/&branch.revision;R/schedule.xml. + This file is continuously updated as the release cycle + progresses. + + + In most cases, the schedule.xml can + be copied from a prior release and updated accordingly. + + + The schedule is also linked from + head/en_US.ISO8859-1/htdocs/releng/index.xml. + + Approximately one month prior to the scheduled code + slush, the &team.re; sends a reminder email to the + &os; Developers. + + Once the first builds of the release cycle are available, + update the beta.local.where entity in + head/en_US.ISO8859-1/htdocs/releases/&branch.revision;R/schedule.xml. + replacing IGNORE with + INCLUDE. + + + If two parallel release cycles are happening at once, the + beta2.local.where entity may be used + instead. + - - Release from <literal>stable/</literal> - - - + &release.terminology; + &release.major.version; + &release.minor.version; + &release.building; + &release.mirrors; + + + Wrapping up the Release Cycle + + This section describes general post-release tasks. + + + Post-Release Errata Notices + + As the release cycle approaches conclusion, it is common + to have several EN (Errata Notice) + candidates to address issues that were discovered late in the + cycle. Following the release, the &team.re; and the + &team.secteam; revisit changes that were not approved prior to + the final release, and depending on the scope of the change in + question, may issue an EN. + + + + Handoff to the &team.secteam; + + Roughly two weeks following the release, the Release + Engineer updates svnadmin/conf/approvers + changing the approver column from re to + (so|security-officer) for the + &branch.relengx; branch. + +

Copied: head/en_US.ISO8859-1/articles/freebsd-releng/extra.css (from r43297, user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/extra.css) ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/en_US.ISO8859-1/articles/freebsd-releng/extra.css Fri Mar 31 22:36:27 2017 (r50119, copy of r43297, user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/extra.css) @@ -0,0 +1,7 @@ +/* + * $FreeBSD$ + */ + +DIV.TITLEPAGE { + text-align: center; +} Copied and modified: head/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml (from r50079, user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml) ============================================================================== --- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml Thu Mar 23 20:32:21 2017 (r50079, copy source) +++ head/en_US.ISO8859-1/articles/freebsd-releng/releng-building.xml Fri Mar 31 22:36:27 2017 (r50119) @@ -34,9 +34,34 @@ options and environment variables. Support for configuration files provided support for cross building each architecture for a release by specifying a separate configuration file for - each invocation. See &man.release.7; and + each invocation. + + As a brief example of using + src/release/release.sh to build a single + release in /scratch: + + &prompt.root; /bin/sh /usr/src/release/release.sh + + As a brief example of using + src/release/release.sh to build a single, + cross-built release using a different target directory, create + a custom release.conf containing: + + # release.sh configuration for powerpc/powerpc64 +CHROOTDIR="/scratch-powerpc64" +TARGET="powerpc" +TARGET_ARCH="powerpc64" +KERNEL="GENERIC64" + + Then invoke src/release/release.sh + as: + + &prompt.root; /bin/sh /usr/src/release/release.sh -c $HOME/release.conf + + See &man.release.7; and src/release/release.conf.sample for more - details. + details and example usage. @@ -54,22 +79,169 @@ The wrapper script is called thermite.sh, which is available in the &os; Subversion repository at - svn://svn.freebsd.org/user/gjb/thermite/, + svn://svn.freebsd.org/base/user/gjb/thermite/, in addition to configuration files used to build &branch.head; and &branch.stablex; development snapshots. + + Using thermite.sh is covered in and . + + Each architecture and individual kernel have their own + configuration file used by release.sh. + Each branch has its own defaults-X.conf + configuration which contains entries common throughout each + architecture, where overrides or special variables are set + and/or overridden in the per-build files. + + The per-build configuration file naming scheme is in the + form of + ${revision}-${TARGET_ARCH}-${KERNCONF}-${type}.conf, + where the uppercase variables are equivalent to what + &man.make.1; uses in the build system, and lowercase variables + are set within the configuration files, mapping to the major + version of the respective branch. + + Each branch also has its own + builds-X.conf configuration, which is + used by thermite.sh. The + thermite.sh script iterates through each + ${revision}, ${TARGET_ARCH}, + ${KERNCONF}, and ${type} value, creating + a master list of what to build. However, a given + combination from the list will only be built if the + respective configuration file exists, which is where the + naming scheme above is relevant. + + There are two paths of file sourcing: + + + + builds-11.conf + -> main.conf + This controls thermite.sh + behavior + + + + 11-amd64-GENERIC-snap.conf + -> + defaults-11.conf + -> main.conf + This controls release/release.sh + behavior within the build &man.chroot.8; + + + + + The + builds-11.conf, + defaults-11.conf, + and main.conf configuration files exist + to reduce repetition between the various per-build + files. + Building &os; Development Snapshots - + The official release build machines have a specific + filesystem layout, which using ZFS, + thermite.sh takes heavy advantage of with + clones and snapshots, ensuring a pristine build + environment. + + The build scripts reside in /releng/scripts-snapshot/scripts + or /releng/scripts-release/scripts + respectfully, to avoid collisions between an + RC build from a releng branch versus + a STABLE snapshot from the respective stable + branch. + + A separate dataset exists for the final build images, + /snap/ftp. This + directory contains both snapshots and releases directories. + They are only used if the EVERYTHINGISFINE + variable is defined in main.conf. + + + The EVERYTHINGISFINE variable name was + chosen to avoid colliding with a variable that might be + possibly set in the user environment, accidentally enabling + the behavior that depends on it being defined. + + + As thermite.sh iterates through the + master list of combinations and locates the per-build + configuration file, a ZFS dataset is created + under /releng, such as + /releng/12-amd64-GENERIC-snap. + The src/, ports/, and + doc/ trees are checked out to separate + ZFS datasets, such as /releng/12-src-snap, which are + then cloned and mounted into the respective build datasets. + This is done to avoid checking out a given tree more than + once. + + Assuming these filesystem paths, + thermite.sh would be invoked as: + + &prompt.root; cd /releng/scripts-snapshot/scripts +&prompt.root; ./setrev.sh -b &branch.stablex; +&prompt.root; ./zfs-setup.sh -c ./builds-11.conf +&prompt.root; ./thermite.sh -c ./builds-11.conf Building &os; Releases - + Similar to building &os; development snapshots, + thermite.sh would be invoked the same way. + The difference between development snapshots and release builds, + BETA and RC, included, is + that the &man.chroot.8; configuration files must be named with + release instead of snap as + the "type", as mentioned above. + + In addition, the BUILDTYPE and + types must be changed from + snap to release in + defaults-11.conf + and + builds-11.conf, + respectively. + + When building BETA, + RC, and the final RELEASE, + also statically set BUILDSVNREV to the + revision on the branch reflecting the name change, + BUILDDATE to the date the builds are started + in YYYYMMDD format. If the + doc/ and ports/ trees have + been tagged, also set PORTBRANCH and + DOCBRANCH to the relevant tag path in the + Subversion repository, replacing HEAD with + the last changed revision. Also set + releasesrc in + builds-11.conf + to the relevant branch, such as &branch.stablex; or + &branch.relengx;. + + After building the final RELEASE, the + &branch.relengx; branch is tagged as &branch.releasex; using the + revision from which the RELEASE was built. + Similar to creating the &branch.stablex; and &branch.relengx; + branches, this is done with svn cp. From the + repository root: + + &prompt.user; svn cp ^/&branch.relengx;@r306420 &branch.releasex; +&prompt.user; svn commit &branch.releasex; Copied and modified: head/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml (from r49954, user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml) ============================================================================== --- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml Thu Feb 9 16:53:39 2017 (r49954, copy source) +++ head/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml Fri Mar 31 22:36:27 2017 (r50119) @@ -4,80 +4,193 @@ $FreeBSD$ --> - - Release from &branch.head; + + Release from &branch.head; - This section describes the general procedures of the &os; - release cycle from the &branch.head; branch. + This section describes the general procedures of the &os; + release cycle from the &branch.head; branch. - - &os; <quote><literal>ALPHA</literal></quote> - Builds - - Starting with the &os; 10.0-RELEASE cycle, the notion - of ALPHA builds was - introduced. Unlike the BETA and - RC builds, ALPHA - builds are not included in the &os; Release schedule. - - The idea behind ALPHA builds is to - provide regular &os;-provided builds before the creation of - the &branch.stable; branch. - - &os; ALPHA snapshots should be built - approximately once a week. - - For the first ALPHA build, the - BRANCH value in - sys/conf/newvers.sh needs to be changed - from CURRENT to ALPHA1. - For subsequent ALPHA builds, increment - each ALPHAN - value by one. - - See for information on - building the ALPHA images. - - - - The <acronym>KBI</acronym>/<acronym>KPI</acronym> - Freeze - - - - - - Creating the &branch.stablex; Branch - - When creating the &branch.stable; branch, several changes - are required in both the new &branch.stable; branch and the - &branch.head; branch. - - - - - - File to Edit - What to Change - - - - - - - - - - - - ?> - - - - Code Thaw in &branch.head; - - - - + + &os; <quote><literal>ALPHA</literal></quote> Builds + + Starting with the &os; 10.0-RELEASE cycle, the notion + of ALPHA builds was + introduced. Unlike the BETA and + RC builds, ALPHA builds + are not included in the &os; Release schedule. + + The idea behind ALPHA builds is to + provide regular &os;-provided builds before the creation of the + &branch.stable; branch. + + &os; ALPHA snapshots should be built + approximately once a week. + + For the first ALPHA build, the + BRANCH value in + sys/conf/newvers.sh needs to be changed + from CURRENT to ALPHA1. + For subsequent ALPHA builds, increment each + ALPHAN value by + one. + + See for information on + building the ALPHA images. + + + + Creating the &branch.stablex; Branch + + When creating the &branch.stable; branch, several changes + are required in both the new &branch.stable; branch and the + &branch.head; branch. The files listed are relative to the + repository root. To create the new &branch.stablex; branch + in Subversion: + + &prompt.user; svn cp head &branch.stablex; + + Once the &branch.stablex; branch has been committed, make + the following edits: + + + + + + File to Edit + What to Change + + + + + + stable/11/UPDATING + Update the &os; version, and remove the notice + about WITNESS + + + + stable/11/contrib/jemalloc/include/jemalloc/jemalloc_FreeBSD.h + #ifndef MALLOC_PRODUCTION +#define MALLOC_PRODUCTION +#endif + + + + stable/11/sys/*/conf/GENERIC* + Remove debugging support + + + + stable/11/release/release.conf.sample + Update SRCBRANCH + + + + stable/11/sys/*/conf/GENERIC-NODEBUG + Remove these kernel configurations + + + + stable/11/sys/conf/newvers.sh + Update the BRANCH value to + reflect BETA1 + + + + + + Then in the &branch.head; branch, which will now become + a new major version: + + + + + + File to Edit + What to Change + + + + + + head/UPDATING + Update the &os; version + + + + head/gnu/usr.bin/groff/tmac/mdoc.local.in + Add the new &os; version + + + + head/sys/conf/newvers.sh + Update the BRANCH value to + reflect CURRENT, and increment + REVISION + + + + head/Makefile.inc1 + Update TARGET_TRIPLE + + + + head/sys/sys/param.h + Update __FreeBSD_version + + + + head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp + Update + __FreeBSD_cc_version + + + + head/gnu/usr.bin/cc/cc_tools/freebsd-native.h + Update FBSD_MAJOR and + FBSD_CC_VER + + + + head/contrib/gcc/config.gcc + Append the + freebsd<version>.h + section + + + + head/release/Makefile + Remove the + debug.witness.trace entries + + + + head/release/doc/en_US.ISO8859-1/readme/article.xml + Replace &a.current; with &a.stable; + + + + head/release/doc/share/xml/release.ent + + + + ?> + + + head/lib/clang/clang.build.mk + Uncomment -DNDEBUG + + + + head/lib/clang/freebsd_cc_version.h + Update + FREEBSD_CC_VERSION + + + + + + Copied and modified: head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml (from r49954, user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml) ============================================================================== --- user/gjb/releng-rewrite/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml Thu Feb 9 16:53:39 2017 (r49954, copy source) +++ head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml Fri Mar 31 22:36:27 2017 (r50119) @@ -10,27 +10,165 @@ This section describes the general procedures of the &os; release cycle from an extablished &branch.stable; branch. + + &os; <literal>stable</literal> Branch Code Slush + + In preparation for the code freeze on + a stable branch, several files need to be + updated to reflect the release cycle is officially in + progress. These files are all relative to the top-most level of + the stable branch: + + + + + + File to Edit + What to Change + + + + + + gnu/usr.bin/groff/tmac/mdoc.local.in + Add the new &os; version + + + + sys/conf/newvers.sh + Update the BRANCH value to + reflect PRERELEASE + + + + Makefile.inc1 + Update TARGET_TRIPLE + + + + + + &os; <literal>BETA</literal> Builds - + Following the code slush, the next phase of the release + cycle is the code freeze. This is the point at which all + commits to the stable branch require explicit approval from + the &team.re;. This is enforced by pre-commit hooks in the + Subversion repository by editing + base/svnadmin/conf/approvers to include + a regular expression matching the &branch.stablex; branch for + the release: + *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Fri Mar 31 22:41:24 2017 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C4C3D27FD6; Fri, 31 Mar 2017 22:41:24 +0000 (UTC) (envelope-from gjb@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 mx1.freebsd.org (Postfix) with ESMTPS id D81A92DB; Fri, 31 Mar 2017 22:41:23 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id v2VMfNeu091615; Fri, 31 Mar 2017 22:41:23 GMT (envelope-from gjb@FreeBSD.org) Received: (from gjb@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id v2VMfMvE091614; Fri, 31 Mar 2017 22:41:22 GMT (envelope-from gjb@FreeBSD.org) Message-Id: <201703312241.v2VMfMvE091614@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gjb set sender to gjb@FreeBSD.org using -f From: Glen Barber Date: Fri, 31 Mar 2017 22:41:22 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r50120 - head/en_US.ISO8859-1/articles/freebsd-releng X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire doc trees $except for " user" , " projects" , and " translations" $" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 22:41:24 -0000 Author: gjb Date: Fri Mar 31 22:41:22 2017 New Revision: 50120 URL: https://svnweb.freebsd.org/changeset/doc/50120 Log: Fix source path in two 'svn cp' examples. Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml Modified: head/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml ============================================================================== --- head/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml Fri Mar 31 22:36:27 2017 (r50119) +++ head/en_US.ISO8859-1/articles/freebsd-releng/releng-major-version.xml Fri Mar 31 22:41:22 2017 (r50120) @@ -48,7 +48,7 @@ repository root. To create the new &branch.stablex; branch in Subversion: - &prompt.user; svn cp head &branch.stablex; + &prompt.user; svn cp ^/head &branch.stablex; Once the &branch.stablex; branch has been committed, make the following edits: Modified: head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml ============================================================================== --- head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml Fri Mar 31 22:36:27 2017 (r50119) +++ head/en_US.ISO8859-1/articles/freebsd-releng/releng-minor-version.xml Fri Mar 31 22:41:22 2017 (r50120) @@ -97,7 +97,7 @@ paths listed below are relative to the repository root. The order of commits and what to change are: - &prompt.user; svn cp &branch.stablex; &branch.relengx; + &prompt.user; svn cp ^/&branch.stablex; &branch.relengx; From owner-svn-doc-all@freebsd.org Sat Apr 1 03:46:55 2017 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE84ED28F53; Sat, 1 Apr 2017 03:46:55 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5232E66; Sat, 1 Apr 2017 03:46:55 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id E485430E; Fri, 31 Mar 2017 22:46:54 -0500 (CDT) Date: Fri, 31 Mar 2017 22:46:53 -0500 From: Mark Linimon To: Glen Barber Cc: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: Re: svn commit: r50119 - in head: en_US.ISO8859-1/articles en_US.ISO8859-1/articles/freebsd-releng en_US.ISO8859-1/articles/releng share/xml Message-ID: <20170401034653.GB25089@lonesome.com> References: <201703312236.v2VMaRIm090736@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201703312236.v2VMaRIm090736@repo.freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire doc trees $except for " user" , " projects" , and " translations" $" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 03:46:56 -0000 On Fri, Mar 31, 2017 at 10:36:27PM +0000, Glen Barber wrote: > Merge the ^/user/gjb/releng-rewrite branch to ^/head, which updates > the Release Engineering process of the Project. Nice to see. mcl

freebsd-ia64@FreeBSD.org	FreeBSD 10 までは Tier 2。それ以降はサポートされません。
FreeBSD/RISC-V Project	freebsd-riscv@FreeBSD.org	FreeBSD 12 から Tier 3

Subversion Administrators <svnadm@>

対応が終了したプラットフォーム

対応していないプラットフォーム