Date: Mon, 29 Dec 2008 15:20:44 GMT From: Rene Ladan <rene@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 155418 for review Message-ID: <200812291520.mBTFKi6G085495@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=155418 Change 155418 by rene@rene_self on 2008/12/29 15:19:49 Undo most FreeBSD to &os; changes, they are considered whitespace commit. Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#9 edit Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#9 (text+ko) ==== @@ -9,7 +9,7 @@ <authorgroup> <author> - <surname>The &os; Documentation Project</surname> + <surname>The FreeBSD Documentation Project</surname> </author> </authorgroup> @@ -26,7 +26,7 @@ <year>2006</year> <year>2007</year> <year>2008</year> - <holder>The &os; Documentation Project</holder> + <holder>The FreeBSD Documentation Project</holder> </copyright> <legalnotice id="trademarks" role="trademarks"> @@ -40,18 +40,18 @@ </legalnotice> <abstract> - <para>This document provides information for the &os; committer + <para>This document provides information for the FreeBSD committer community. All new committers should read this document before they start, and existing committers are strongly encouraged to review it from time to time.</para> - <para>Almost all &os; developers have commmit rights to one or + <para>Almost all FreeBSD developers have commmit rights to one or more repositories. However, a few developers do not, and some of the information here applies to them as well. (For instance, some people only have rights to work with the Problem Report database). Please see <xref linkend="non-committers"> for more information.</para> - <para>This document may also be of interest to members of the &os; + <para>This document may also be of interest to members of the FreeBSD community who want to learn more about how the project works.</para> </abstract> </articleinfo> @@ -140,10 +140,10 @@ <sect1 id="committer.types"> <title>Commit Bit Types</title> - <para>The &os; CVS repository has a number of components which, + <para>The FreeBSD CVS repository has a number of components which, when combined, support the basic operating system source, documentation, third party application ports infrastructure, and - various maintained utilities. When &os; commit bits are + various maintained utilities. When FreeBSD commit bits are allocated, the areas of the tree where the bit may be used are specified. Generally, the areas associated with a bit reflect who authorized the allocation of the commit bit. Additional areas of @@ -282,7 +282,7 @@ via <application>CVSup</application> for the convenience of our users.</para> <note><para>Note that the <literal>www</literal> module containing sources - for the <ulink url="http://www.FreeBSD.org">&os; website</ulink> is + for the <ulink url="http://www.FreeBSD.org">FreeBSD website</ulink> is contained within the <literal>doc</literal> repository.</para></note> <para>The CVS repositories are hosted on the repository machines. @@ -383,7 +383,7 @@ linkend="repomeisters">repomeister</link> will copy the file(s) to their new name and/or location and let you know when it is done. The purpose of a repository copy is to preserve file - change history, or logs. We in the &os; Project greatly + change history, or logs. We in the FreeBSD Project greatly value the change history that CVS gives to the project.</para> <para>CVS reference information, tutorials, and FAQs can be found at: @@ -436,7 +436,7 @@ </tgroup> </table> - <para>Practical &os; examples:</para> + <para>Practical FreeBSD examples:</para> <itemizedlist> <listitem> @@ -751,7 +751,7 @@ </itemizedlist> <para>You will almost certainly get a conflict because - of the <literal>$Id$</literal> (or in &os;'s case, + of the <literal>$Id$</literal> (or in FreeBSD's case, <literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>) lines, so you will have to edit the file to resolve the conflict (remove the marker lines and the second <literal>$Id$</literal> line, @@ -1188,7 +1188,7 @@ will have any idea who you are or what you are working on. You do not have to write a comprehensive biography, just write a paragraph or two about who you are and what you plan to be working on as a - developer in &os;. (You should also mention who your mentor + developer in FreeBSD. (You should also mention who your mentor will be). Email this to the &a.developers; and you will be on your way!</para> </listitem> @@ -1356,7 +1356,7 @@ If they see a different solution to a problem than you, or even a different problem, it is not because they are stupid, because they have questionable parentage, or because they are trying to - destroy your hard work, personal image, or &os;, but simply + destroy your hard work, personal image, or FreeBSD, but simply because they have a different outlook on the world. Different is good.</para> @@ -1380,7 +1380,7 @@ <sect1 id="gnats"> <title>GNATS</title> - <para>The &os; Project utilizes + <para>The FreeBSD Project utilizes <application>GNATS</application> for tracking bugs and change requests. Be sure that if you commit a fix or suggestion found in a <application>GNATS</application> PR, you use @@ -1409,7 +1409,7 @@ </listitem> </itemizedlist> - <para>You can run a local copy of GNATS, and then integrate the &os; + <para>You can run a local copy of GNATS, and then integrate the FreeBSD GNATS tree in to it using CVSup. Then you can run the GNATS commands locally. This lets you query the PR database without needing to be connected to @@ -1428,7 +1428,7 @@ <programlisting>gnats release=current prefix=/usr</programlisting> - <para>This will place the &os; GNATS tree in + <para>This will place the FreeBSD GNATS tree in <filename>/usr/gnats</filename>. You can use a <emphasis>refuse</emphasis> file to control which categories to receive. For example, to only receive <literal>docs</literal> PRs, @@ -1472,7 +1472,7 @@ <programlisting># This category is mandatory pending:Category for faulty PRs:gnats-admin: # -# &os; categories +# FreeBSD categories # docs:Documentation Bug:freebsd-doc:</programlisting> </step> @@ -1512,7 +1512,7 @@ <title>Who's Who</title> <para>Besides the repository - meisters, there are other &os; project members and teams whom you will + meisters, there are other FreeBSD project members and teams whom you will probably get to know in your role as a committer. Briefly, and by no means all-inclusively, these are:</para> @@ -1539,7 +1539,7 @@ <listitem> <para>doceng is the group responsible for the documentation build infrastructure, approving new documentation committers, and - ensuring that the &os; website and documentation on the FTP + ensuring that the FreeBSD website and documentation on the FTP site is up to date with respect to the CVS tree. It is not a conflict resolution body. The vast majority of documentation related discussion takes place on the &a.doc;. More details regarding the doceng team can be found in its <ulink url="http://www.FreeBSD.org/internal/doceng.html">charter</ulink>. Committers @@ -1568,7 +1568,7 @@ When you do a commit that could have been done better, Bruce will be there to tell you. Be thankful that someone is. Bruce is also very knowledgeable on the various - standards applicable to &os;.</para> + standards applicable to FreeBSD.</para> </listitem> </varlistentry> @@ -1604,7 +1604,7 @@ <listitem> <para>Colin is the - <ulink url="&url.base;/security/">&os; Security + <ulink url="&url.base;/security/">FreeBSD Security Officer</ulink> and oversees the &a.security-officer;. </para> @@ -1619,7 +1619,7 @@ are not sure of some potential change to the networking subsystem you have in mind, Garrett is someone to talk to. Garrett is also very knowledgeable on the various - standards applicable to &os;.</para> + standards applicable to FreeBSD.</para> </listitem> </varlistentry> @@ -1644,12 +1644,12 @@ voting, announcements, etc.</para> <para>The &a.developers; is for the exclusive use of - &os; committers. In order to develop &os;, committers must + FreeBSD committers. In order to develop FreeBSD, committers must have the ability to openly discuss matters that will be resolved before they are publicly announced. Frank discussions of work in - progress are not suitable for open publication and may harm &os;.</para> + progress are not suitable for open publication and may harm FreeBSD.</para> - <para>All &os; committers are reminded to obey the copyright of the + <para>All FreeBSD committers are reminded to obey the copyright of the original author(s) of &a.developers; mail. Do not publish or forward messages from the &a.developers; outside the list membership without permission of all of the authors.</para> @@ -1662,12 +1662,12 @@ <para>This list is <emphasis>not</emphasis> intended as a place for code reviews or a replacement for the &a.arch; or the &a.audit;. In fact - using it as such hurts the &os; Project as it gives a sense of a - closed list where general decisions affecting all of the &os; + using it as such hurts the FreeBSD Project as it gives a sense of a + closed list where general decisions affecting all of the FreeBSD using community are made without being <quote>open</quote>. Last, but not least <emphasis>never, never ever, email - the &a.developers; and CC:/BCC: another &os; list</emphasis>. - Never, ever email another &os; email list and CC:/BCC: + the &a.developers; and CC:/BCC: another FreeBSD list</emphasis>. + Never, ever email another FreeBSD email list and CC:/BCC: the &a.developers;. Doing so can greatly diminish the benefits of this list.</para> </listitem> @@ -1790,7 +1790,7 @@ </sect1> <sect1 id="rules"> - <title>The &os; Committers' Big List of Rules</title> + <title>The FreeBSD Committers' Big List of Rules</title> <orderedlist> <listitem> @@ -1998,7 +1998,7 @@ <listitem> <para>Respect existing maintainers if listed.</para> - <para>Many parts of &os; are not <quote>owned</quote> in + <para>Many parts of FreeBSD are not <quote>owned</quote> in the sense that any specific individual will jump up and yell if you commit a change to <quote>their</quote> area, but it still pays to check first. One convention we use @@ -2017,8 +2017,8 @@ question and see if someone has been working recently or predominantly in that area.</para> - <para>Other areas of &os; fall under the control of - someone who manages an overall category of &os; + <para>Other areas of FreeBSD fall under the control of + someone who manages an overall category of FreeBSD evolution, such as internationalization or networking. See <ulink url="&url.base;/administration.html"> @@ -2135,7 +2135,7 @@ and committing 10 megabytes worth of accumulated stuff. People who abuse this on a regular basis will have their commit privileges suspended until they get back from the - &os; Happy Reeducation Camp we run in Greenland.</para> + FreeBSD Happy Reeducation Camp we run in Greenland.</para> </listitem> <listitem> @@ -2168,9 +2168,9 @@ running that code. If you have a change which also may break another architecture, be sure and test on all supported architectures. Please refer to the <ulink - url="http://www.FreeBSD.org/internal/">&os; Internal + url="http://www.FreeBSD.org/internal/">FreeBSD Internal Page</ulink> for a list of available resources. As other - architectures are added to the &os; supported platforms + architectures are added to the FreeBSD supported platforms list, the appropriate shared testing resources will be made available.</para> </listitem> @@ -2209,9 +2209,9 @@ <sect2> <title>Policy on Multiple Architectures</title> - <para>&os; has added several new architecture ports during recent + <para>FreeBSD has added several new architecture ports during recent release cycles and is truly no longer an &i386; centric operating - system. In an effort to make it easier to keep &os; portable + system. In an effort to make it easier to keep FreeBSD portable across the platforms we support, core has developed the following mandate:</para> @@ -2307,39 +2307,39 @@ <sect1 id="archs"> <title>Support for Multiple Architectures</title> - <para>&os; is a highly portable operating system intended to + <para>FreeBSD is a highly portable operating system intended to function on many different types of hardware architectures. Maintaining clean separation of Machine Dependent (MD) and Machine Independent (MI) code, as well as minimizing MD code, is an important part of our strategy to remain agile with regards to current hardware trends. Each new hardware architecture supported by - &os; adds substantially to the cost of code maintenance, + FreeBSD adds substantially to the cost of code maintenance, toolchain support, and release engineering. It also dramatically increases the cost of effective testing of kernel changes. As such, there is strong motivation to differentiate between classes of support for various architectures while remaining strong in a few - key architectures that are seen as the &os; "target audience". + key architectures that are seen as the FreeBSD "target audience". </para> <sect2> <title>Statement of General Intent</title> - <para>The &os; Project targets "production quality commercial + <para>The FreeBSD Project targets "production quality commercial off-the-shelf (COTS) workstation, server, and high-end embedded systems". By retaining a focus on a narrow set of architectures - of interest in these environments, the &os; Project is able + of interest in these environments, the FreeBSD Project is able to maintain high levels of quality, stability, and performance, as well as minimize the load on various support teams on the project, such as the ports team, documentation team, security officer, and release engineering teams. Diversity in - hardware support broadens the options for &os; consumers by + hardware support broadens the options for FreeBSD consumers by offering new features and usage opportunities (such as support for 64 bit CPUs, use in embedded environments, etc.), but these benefits must always be carefully considered in terms of the real-world maintenance cost associated with additional platform support. </para> - <para>The &os; Project differentiates platform targets into + <para>The FreeBSD Project differentiates platform targets into four tiers. Each tier includes a specification of the requirements for an architecture to be in that tier, as well as specifying the obligations of developers with @@ -2360,11 +2360,11 @@ requirement). In general, all Tier 1 platforms must have build and Tinderbox support either in the FreeBSD.org cluster, or be easily available for all developers. Embedded platforms may - substitute an emulator available in the &os; cluster for + substitute an emulator available in the FreeBSD cluster for actual hardware.</para> <para>Tier 1 architectures are expected to be Production Quality - with respects to all aspects of the &os; operating system, + with respects to all aspects of the FreeBSD operating system, including installation and development environments.</para> <para>Tier 1 architectures are expected to be completely @@ -2404,19 +2404,19 @@ maintainer is expected to work with the platform maintainers to refine these changes. Major new toolchain components are allowed to break support for Tier 2 architectures if the - &os;-local changes have not been incorporated upstream. The + FreeBSD-local changes have not been incorporated upstream. The toolchain maintainers are expected to provide prompt review of any proposed changes and cannot block, through their inaction, - changes going into the tree. New features added to &os; + changes going into the tree. New features added to FreeBSD should be feasible to implement on these platforms, but an implementation is not required before the feature may be added - to the &os; source tree. New features that may be difficult + to the FreeBSD source tree. New features that may be difficult to implement on Tier 2 architectures should provide a means of disabling them on those architectures. The implementation of - a Tier 2 architecture may be committed to the main &os; + a Tier 2 architecture may be committed to the main FreeBSD tree as long as it does not interfere with production work on Tier 1 platforms, or substantially with other Tier 2 platforms. - Before a Tier 2 platform can be added to the &os; base + Before a Tier 2 platform can be added to the FreeBSD base source tree, the platform must be able to boot multi-user on actual hardware. Generally, there must be at least three active developers working on the platform.</para> @@ -2436,12 +2436,12 @@ system, some external patches for the architecture for ports must be available.</para> - <para>Tier 2 architectures can be integrated into the &os; + <para>Tier 2 architectures can be integrated into the FreeBSD handbook. The basics for how to get a system running must be documented, although not necessarily for every single board or system a Tier 2 architecture supports. The supported hardware list must exist and should be no more than a couple of months - old. It should be integrated into the &os; + old. It should be integrated into the FreeBSD documentation.</para> <para>Current Tier 2 platforms are ARM, PowerPC, ia64, Sparc64 and @@ -2459,11 +2459,11 @@ are considered legacy systems unlikely to see broad future use. New Tier 3 systems will not be committed to the base source tree. Support for Tier 3 systems may be worked on in - the &os; Perforce Repository, providing source control and - easier change integration from the main &os; tree. + the FreeBSD Perforce Repository, providing source control and + easier change integration from the main FreeBSD tree. Platforms that transition to Tier 3 status may be removed from the tree if they are no longer actively supported by the - &os; developer community at the discretion of the release + FreeBSD developer community at the discretion of the release engineer.</para> <para>Tier 3 platforms may have ports support, either integrated @@ -2472,7 +2472,7 @@ <para>Tier 3 platforms must have the basics documented for how to build a kernel and how to boot it on at least one target hardware or emulation environment. This documentation need - not be integrated into the &os; tree.</para> + not be integrated into the FreeBSD tree.</para> <para>Current Tier 3 platforms are MIPS and &s390;.</para> </sect2> @@ -2491,7 +2491,7 @@ <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 + approval of the FreeBSD Core Team, which shall make that decision in collaboration with the Security Officer, Release Engineering, and toolchain maintenance teams.</para> </sect2> @@ -2559,7 +2559,7 @@ contributed to the Project before, add that person's name to the <ulink url="&url.articles.contributors;/contrib-additional.html">Additional - Contributors</ulink> section of the &os; Contributors + Contributors</ulink> section of the FreeBSD Contributors List.</para> <para>Close the PR if the port came in as a PR. To close @@ -3233,7 +3233,7 @@ <sect1 id="non-committers"> <title>Issues Specific To Developers Who Are Not Committers</title> - <para>A few people who have access to the &os; machines do not + <para>A few people who have access to the FreeBSD machines do not have commit bits. For instance, the project is willing to give access to the GNATS database to contributors who have shown interest and dedication in working on Problem Reports.</para> @@ -3277,7 +3277,7 @@ <listitem> <para> - <link linkend="rules">The &os; Committers' Big List of Rules</link> + <link linkend="rules">The FreeBSD Committers' Big List of Rules</link> <para> </listitem> </itemizedlist> @@ -3411,14 +3411,14 @@ <entry><literal>Submitted by:</literal></entry> <entry>The name and e-mail address of the person that submitted the fix; for committers, just the username on - the &os; cluster.</entry> + the FreeBSD cluster.</entry> </row> <row> <entry><literal>Reviewed by:</literal></entry> <entry>The name and e-mail address of the person or people that reviewed the change; for committers, just the - username on the &os; cluster. If a patch was + username on the FreeBSD cluster. If a patch was submitted to a mailing list for review, and the review was favorable, then just include the list name.</entry> </row> @@ -3427,7 +3427,7 @@ <entry><literal>Approved by:</literal></entry> <entry>The name and e-mail address of the person or people that approved the change; for committers, just the - username on the &os; cluster. It is customary to get + username on the FreeBSD cluster. It is customary to get prior approval for a commit if it is to an area of the tree to which you do not usually commit. In addition, during the run up to a new release all commits @@ -3587,7 +3587,7 @@ <answer> <para>The mailing lists are archived under <filename>/g/mail</filename> which will show up as <filename>/hub/g/mail</filename> with &man.pwd.1;. - This location is accessible from any machine on the &os; cluster.</para> + This location is accessible from any machine on the FreeBSD cluster.</para> </answer> </qandaentry>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812291520.mBTFKi6G085495>