os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

A HREF="mailto:maillist" -> A HREF="mailto:maillist@FreeBSD.org"

Browse source 
"phraze" -> <qoute>phraze</quote>

Reviewed by:	maintainer
This commit is contained in:
Alexey Zelkin 1999-10-15 12:46:41 +00:00
parent 047e9d65b2
commit c7e21561e5
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=5861
2 changed files with 26 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
en_US.ISO8859-1/articles/committers-guide/article.sgml
View file

@ -498,8 +498,8 @@
or, upon repeated offense, permanent removal of commit privileges. or, upon repeated offense, permanent removal of commit privileges.
Three or more members of core, or the Principal Architect and another Three or more members of core, or the Principal Architect and another
member of core acting in unison, have the power to temporarily suspend member of core acting in unison, have the power to temporarily suspend
commit privileges until -core as a whole has the chance to review the commit privileges until <literal>-core</literal> as a whole has the chance to review the
issue. In cases of "emergency" (a committer doing damage to the issue. In cases of <quote>emergency</quote> (a committer doing damage to the
repository), a temporary suspension may also be done by the repository repository), a temporary suspension may also be done by the repository
meisters or any other member of core who may happen to be awake at the meisters or any other member of core who may happen to be awake at the
time. Only core as a whole has the authority to suspend commit time. Only core as a whole has the authority to suspend commit
@ -602,7 +602,7 @@
for documentation on this. Where sections of code have several for documentation on this. Where sections of code have several
maintainers, commits to affected areas by one maintainer need to maintainers, commits to affected areas by one maintainer need to
be reviewed by at least one other maintainer. In cases where the be reviewed by at least one other maintainer. In cases where the
"maintainer-ship" of something isn't clear, you can also look at <quote>maintainer-ship</quote> of something isn't clear, you can also look at
the CVS logs for the file(s) in question and see if someone has the CVS logs for the file(s) in question and see if someone has
been working recently or predominantly in that area.</para> been working recently or predominantly in that area.</para>
@ -663,7 +663,7 @@
The release engineer has the same authority over the -stable The release engineer has the same authority over the -stable
branch as outlined in rule #5.</para> branch as outlined in rule #5.</para>
<para>This is another "don't argue about it" issue since it's the <para>This is another <quote>don't argue about it</quote> issue since it's the
release engineer who is ultimately responsible (and gets beaten release engineer who is ultimately responsible (and gets beaten
up) if a change turns out to be bad. Please respect this and give up) if a change turns out to be bad. Please respect this and give
the release engineer your full cooperation when it comes to the the release engineer your full cooperation when it comes to the
@ -748,7 +748,7 @@
running that code. If you have a change which also may break running that code. If you have a change which also may break
another architecture, be sure and test on all supported another architecture, be sure and test on all supported
architectures. Currently, this is only the x86 and the alpha so architectures. Currently, this is only the x86 and the alpha so
it's pretty easy to do. If you need to test on the axp, your it's pretty easy to do. If you need to test on the AXP, your
account on <hostid role="fqdn">beast.FreeBSD.org</hostid> will let account on <hostid role="fqdn">beast.FreeBSD.org</hostid> will let
you compile and test alpha binaries/kernels/etc. As other you compile and test alpha binaries/kernels/etc. As other
architectures are added to the FreeBSD supported platforms list, architectures are added to the FreeBSD supported platforms list,
@ -766,7 +766,7 @@
also verify that your formatting directives are correct by running also verify that your formatting directives are correct by running
<command>make lint</command>.</para> <command>make lint</command>.</para>
<para>For all on-line manual pages, run 'manck' (from ports) over the <para>For all on-line manual pages, run <command>manck</command> (from ports) over the
man page to verify the all of the cross references and file references man page to verify the all of the cross references and file references
are correct and that the man page has all of the appropriate are correct and that the man page has all of the appropriate
<makevar>MLINK</makevar>s installed.</para> <makevar>MLINK</makevar>s installed.</para>
@ -1001,8 +1001,8 @@
<answer> <answer>
<para>The ports manager will send out warning messages to <para>The ports manager will send out warning messages to
the <email>freebsd-ports</email> and the <email>freebsd-ports@FreeBSD.org</email> and
<email>cvs-committers</email> mailing lists announcing <email>cvs-committers@FreeBSD.org</email> mailing lists announcing
the start of the impending release, usually two or three the start of the impending release, usually two or three
weeks in advance. The exact starting time will not be weeks in advance. The exact starting time will not be
determined until a few days before the actual release. determined until a few days before the actual release.
@ -1011,8 +1011,8 @@
when exactly the release will be rolled.</para> when exactly the release will be rolled.</para>
<para>When the freeze starts, there will be another <para>When the freeze starts, there will be another
announcement to the <email>cvs-committers</email> list, announcement to the <email>cvs-committers@FreeBSD.org</email>
of course.</para> list, of course.</para>
</answer> </answer>
</qandaentry> </qandaentry>
@ -1023,8 +1023,9 @@
<answer> <answer>
<para>A few hours after the release, the ports manager <para>A few hours after the release, the ports manager
will send out a mail to the <email>freebsd-ports</email> will send out a mail to the
and <email>cvs-committers</email> mailing lists <email>freebsd-ports@FreeBSD.org</email> and
<email>cvs-committers@FreeBSD.org</email> mailing lists
announcing the end of the ports freeze. Note that the announcing the end of the ports freeze. Note that the
release being cut does not automatically end the freeze. release being cut does not automatically end the freeze.
We have to make sure there will not be any last minute We have to make sure there will not be any last minute

25
en_US.ISO_8859-1/articles/committers-guide/article.sgml
View file

@ -498,8 +498,8 @@
or, upon repeated offense, permanent removal of commit privileges. or, upon repeated offense, permanent removal of commit privileges.
Three or more members of core, or the Principal Architect and another Three or more members of core, or the Principal Architect and another
member of core acting in unison, have the power to temporarily suspend member of core acting in unison, have the power to temporarily suspend
commit privileges until -core as a whole has the chance to review the commit privileges until <literal>-core</literal> as a whole has the chance to review the
issue. In cases of "emergency" (a committer doing damage to the issue. In cases of <quote>emergency</quote> (a committer doing damage to the
repository), a temporary suspension may also be done by the repository repository), a temporary suspension may also be done by the repository
meisters or any other member of core who may happen to be awake at the meisters or any other member of core who may happen to be awake at the
time. Only core as a whole has the authority to suspend commit time. Only core as a whole has the authority to suspend commit
@ -602,7 +602,7 @@
for documentation on this. Where sections of code have several for documentation on this. Where sections of code have several
maintainers, commits to affected areas by one maintainer need to maintainers, commits to affected areas by one maintainer need to
be reviewed by at least one other maintainer. In cases where the be reviewed by at least one other maintainer. In cases where the
"maintainer-ship" of something isn't clear, you can also look at <quote>maintainer-ship</quote> of something isn't clear, you can also look at
the CVS logs for the file(s) in question and see if someone has the CVS logs for the file(s) in question and see if someone has
been working recently or predominantly in that area.</para> been working recently or predominantly in that area.</para>
@ -663,7 +663,7 @@
The release engineer has the same authority over the -stable The release engineer has the same authority over the -stable
branch as outlined in rule #5.</para> branch as outlined in rule #5.</para>
<para>This is another "don't argue about it" issue since it's the <para>This is another <quote>don't argue about it</quote> issue since it's the
release engineer who is ultimately responsible (and gets beaten release engineer who is ultimately responsible (and gets beaten
up) if a change turns out to be bad. Please respect this and give up) if a change turns out to be bad. Please respect this and give
the release engineer your full cooperation when it comes to the the release engineer your full cooperation when it comes to the
@ -748,7 +748,7 @@
running that code. If you have a change which also may break running that code. If you have a change which also may break
another architecture, be sure and test on all supported another architecture, be sure and test on all supported
architectures. Currently, this is only the x86 and the alpha so architectures. Currently, this is only the x86 and the alpha so
it's pretty easy to do. If you need to test on the axp, your it's pretty easy to do. If you need to test on the AXP, your
account on <hostid role="fqdn">beast.FreeBSD.org</hostid> will let account on <hostid role="fqdn">beast.FreeBSD.org</hostid> will let
you compile and test alpha binaries/kernels/etc. As other you compile and test alpha binaries/kernels/etc. As other
architectures are added to the FreeBSD supported platforms list, architectures are added to the FreeBSD supported platforms list,
@ -766,7 +766,7 @@
also verify that your formatting directives are correct by running also verify that your formatting directives are correct by running
<command>make lint</command>.</para> <command>make lint</command>.</para>
<para>For all on-line manual pages, run 'manck' (from ports) over the <para>For all on-line manual pages, run <command>manck</command> (from ports) over the
man page to verify the all of the cross references and file references man page to verify the all of the cross references and file references
are correct and that the man page has all of the appropriate are correct and that the man page has all of the appropriate
<makevar>MLINK</makevar>s installed.</para> <makevar>MLINK</makevar>s installed.</para>
@ -1001,8 +1001,8 @@
<answer> <answer>
<para>The ports manager will send out warning messages to <para>The ports manager will send out warning messages to
the <email>freebsd-ports</email> and the <email>freebsd-ports@FreeBSD.org</email> and
<email>cvs-committers</email> mailing lists announcing <email>cvs-committers@FreeBSD.org</email> mailing lists announcing
the start of the impending release, usually two or three the start of the impending release, usually two or three
weeks in advance. The exact starting time will not be weeks in advance. The exact starting time will not be
determined until a few days before the actual release. determined until a few days before the actual release.
@ -1011,8 +1011,8 @@
when exactly the release will be rolled.</para> when exactly the release will be rolled.</para>
<para>When the freeze starts, there will be another <para>When the freeze starts, there will be another
announcement to the <email>cvs-committers</email> list, announcement to the <email>cvs-committers@FreeBSD.org</email>
of course.</para> list, of course.</para>
</answer> </answer>
</qandaentry> </qandaentry>
@ -1023,8 +1023,9 @@
<answer> <answer>
<para>A few hours after the release, the ports manager <para>A few hours after the release, the ports manager
will send out a mail to the <email>freebsd-ports</email> will send out a mail to the
and <email>cvs-committers</email> mailing lists <email>freebsd-ports@FreeBSD.org</email> and
<email>cvs-committers@FreeBSD.org</email> mailing lists
announcing the end of the ports freeze. Note that the announcing the end of the ports freeze. Note that the
release being cut does not automatically end the freeze. release being cut does not automatically end the freeze.
We have to make sure there will not be any last minute We have to make sure there will not be any last minute