Whitespace cleanups. Translators can ignore.
This commit is contained in:
John Baldwin
parent
ca05ae7e42
commit
de56fa420c
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=6482
2 changed files with 718 additions and 598 deletions
|
|
@ -185,10 +185,13 @@
|
|||
(where <replaceable>user</replaceable> is your username) file
|
||||
containing the e-mail address where you want mail addressed
|
||||
to <replaceable>yourusername</replaceable>@FreeBSD.org
|
||||
to be forwarded. This includes all of the commit messages as well as any other mail addressed to <email>cvs-committers@FreeBSD.org</email>. Really large mailboxes which have taken up
|
||||
permanent residence on <hostid>hub</hostid> often get
|
||||
<quote>accidently</quote> truncated without warning, so forward
|
||||
it or read it and you will not lose it.</para>
|
||||
to be forwarded. This includes all of the commit messages as
|
||||
well as any other mail addressed to
|
||||
<email>cvs-committers@FreeBSD.org</email>. Really large
|
||||
mailboxes which have taken up permanent residence on
|
||||
<hostid>hub</hostid> often get <quote>accidently</quote>
|
||||
truncated without warning, so forward it or read it and you will
|
||||
not lose it.</para>
|
||||
|
||||
<para>All new committers also have a mentor assigned to them for
|
||||
the first few months. Your mentor is more or less responsible for
|
||||
|
|
@ -216,15 +219,20 @@
|
|||
areas, to our shame), the same applies. If, however, you are
|
||||
about to modify something which is clearly being actively
|
||||
maintained by someone else (and it is only by watching the
|
||||
<literal>cvs-committers</literal> mailing list that you can really get
|
||||
a feel for just what is and is not) then consider sending the
|
||||
change to them instead, just as you would have before becoming a
|
||||
committer. For ports, you should contact the listed
|
||||
<makevar>MAINTAINER</makevar> in the
|
||||
<literal>cvs-committers</literal> mailing list that you can
|
||||
really get a feel for just what is and is not) then consider
|
||||
sending the change to them instead, just as you would have
|
||||
before becoming a committer. For ports, you should contact the
|
||||
listed <makevar>MAINTAINER</makevar> in the
|
||||
<filename>Makefile</filename>. For other parts of the
|
||||
repository, if you are unsure who the active maintainer might
|
||||
be, it may help to scan the output of <command>cvs log</command>
|
||||
to see who has committed changes in the past. &a.fenner; has written a nice shell script that can help determine who the active maintainer might be. It lists each person who has committed to a given file along with the number of commits each person has made. It can be found on <hostid>freefall</hostid> at <filename>~fenner/bin/whodid</filename>. If your queries go
|
||||
to see who has committed changes in the past. &a.fenner; has
|
||||
written a nice shell script that can help determine who the
|
||||
active maintainer might be. It lists each person who has
|
||||
committed to a given file along with the number of commits each
|
||||
person has made. It can be found on <hostid>freefall</hostid>
|
||||
at <filename>~fenner/bin/whodid</filename>. If your queries go
|
||||
unanswered or the committer otherwise indicates a lack of
|
||||
proprietary interest in the area affected, go ahead and commit
|
||||
it.</para>
|
||||
|
|
@ -289,10 +297,11 @@
|
|||
<term>&a.asami;</term>
|
||||
|
||||
<listitem>
|
||||
<para>Satoshi is the Ports Wraith, meaning that he has ultimate
|
||||
authority over any modifications to the ports collection or
|
||||
the ports skeleton makefiles. He is also the one responsible for
|
||||
administering code freezes before the releases.</para>
|
||||
<para>Satoshi is the Ports Wraith, meaning that he has
|
||||
ultimate authority over any modifications to the ports
|
||||
collection or the ports skeleton makefiles. He is also
|
||||
the one responsible for administering code freezes before
|
||||
the releases.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -300,9 +309,9 @@
|
|||
<term>&a.bde;</term>
|
||||
|
||||
<listitem>
|
||||
<para>Bruce is the Obersturmbahnfuhrer of the Style Police. When you
|
||||
do a commit that could have been done better, Bruce will
|
||||
be there to tell you. Be thankful that someone
|
||||
<para>Bruce is the Obersturmbahnfuhrer of the Style Police.
|
||||
When you do a commit that could have been done better,
|
||||
Bruce will be there to tell you. Be thankful that someone
|
||||
is.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -311,14 +320,13 @@
|
|||
<term>&a.dg;</term>
|
||||
|
||||
<listitem>
|
||||
<para>David is our principal architect and overseer of the VM
|
||||
system. If you have a VM system change in mind,
|
||||
<para>David is our principal architect and overseer of the
|
||||
VM system. If you have a VM system change in mind,
|
||||
coordinate it with David. Should you become locked in a
|
||||
bitter, intractable dispute with some other committer over
|
||||
a proposed change (which does not happen very often,
|
||||
thankfully) then an appeal to David to put on his P.A. hat
|
||||
and make a final decision might be
|
||||
necessary.</para>
|
||||
and make a final decision might be necessary.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -399,14 +407,15 @@
|
|||
</step>
|
||||
|
||||
<step>
|
||||
<para>If you do not wish to to type your password in every time
|
||||
you use &man.ssh.1;, and you use RSA keys to authenticate,
|
||||
&man.ssh-agent.1; is there for your convenience. If
|
||||
you want to use &man.ssh-agent.1;, make sure that you run it
|
||||
before running other applications. X users, for example,
|
||||
usually do this from their <filename>.xsession</filename> or
|
||||
<filename>.xinitrc</filename> file.
|
||||
See &man.ssh-agent.1; for details.</para>
|
||||
<para>If you do not wish to to type your password in every
|
||||
time you use &man.ssh.1;, and you use RSA keys to
|
||||
authenticate, &man.ssh-agent.1; is there for your
|
||||
convenience. If you want to use &man.ssh-agent.1;, make
|
||||
sure that you run it before running other applications. X
|
||||
users, for example, usually do this from their
|
||||
<filename>.xsession</filename> or
|
||||
<filename>.xinitrc</filename> file. See &man.ssh-agent.1;
|
||||
for details.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
|
|
@ -453,47 +462,54 @@
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Discuss any significant change <emphasis>before</emphasis>
|
||||
committing.</para>
|
||||
<para>Discuss any significant change
|
||||
<emphasis>before</emphasis> committing.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Respect existing maintainers if listed in the
|
||||
(<makevar>MAINTAINER</makevar> field in
|
||||
<filename>Makefile</filename> or in the <filename>MAINTAINER</filename>
|
||||
file in the top-level directory).</para>
|
||||
<filename>Makefile</filename> or in the
|
||||
<filename>MAINTAINER</filename> file in the top-level
|
||||
directory).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Never touch the repository directly. Ask a Repomeister.</para>
|
||||
<para>Never touch the repository directly. Ask a
|
||||
Repomeister.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Any disputed change must be backed out pending resolution of
|
||||
the dispute if requested by a maintainer or the Principal
|
||||
Architect. Security related changes may override a maintainer's
|
||||
wishes at the Security Officer's discretion.</para>
|
||||
<para>Any disputed change must be backed out pending
|
||||
resolution of the dispute if requested by a maintainer or
|
||||
the Principal Architect. Security related changes may
|
||||
override a maintainer's wishes at the Security Officer's
|
||||
discretion.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before <literal>-STABLE</literal> unless specifically
|
||||
permitted by the release engineer or unless they're not applicable
|
||||
to <literal>-CURRENT</literal>. Any non-trivial or non-urgent change which is
|
||||
applicable should also be allowed to sit in <literal>-CURRENT</literal> for at least 3
|
||||
days before merging so that it can be given sufficient testing. The
|
||||
release engineer has the same authority over the <literal>-STABLE</literal> branch as
|
||||
outlined for the Principal Architect in rule #5.</para>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before
|
||||
<literal>-STABLE</literal> unless specifically permitted by
|
||||
the release engineer or unless they're not applicable to
|
||||
<literal>-CURRENT</literal>. Any non-trivial or non-urgent
|
||||
change which is applicable should also be allowed to sit in
|
||||
<literal>-CURRENT</literal> for at least 3 days before
|
||||
merging so that it can be given sufficient testing. The
|
||||
release engineer has the same authority over the
|
||||
<literal>-STABLE</literal> branch as outlined for the
|
||||
Principal Architect in rule #5.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't fight in public with other committers; it looks bad. If
|
||||
you must <quote>strongly disagree</quote> about something, do so only in
|
||||
private.</para>
|
||||
<para>Don't fight in public with other committers; it looks
|
||||
bad. If you must <quote>strongly disagree</quote> about
|
||||
something, do so only in private.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Respect all code freezes and read the <literal>committers</literal> mailing list on
|
||||
a timely basis so you know when a code freeze is in effect.</para>
|
||||
<para>Respect all code freezes and read the
|
||||
<literal>committers</literal> mailing list on a timely basis
|
||||
so you know when a code freeze is in effect.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -505,40 +521,45 @@
|
|||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>As noted, breaking some of these rules can be grounds for suspension
|
||||
or, upon repeated offense, permanent removal of commit privileges.
|
||||
Three or more members of core, or the Principal Architect and another
|
||||
member of core acting in unison, have the power to temporarily suspend
|
||||
commit privileges until <literal>-core</literal> as a whole has the chance to review the
|
||||
issue. In case of an <quote>emergency</quote> (a committer doing damage to the
|
||||
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
|
||||
time. Only core as a whole has the authority to suspend commit
|
||||
privileges for any significant length of time or to remove them
|
||||
permanently, the latter generally only being done after consultation
|
||||
with committers. This rule does not exist to set core up as a bunch of
|
||||
cruel dictators who can dispose of committers as casually as empty soda
|
||||
cans, but to give the project a kind of safety fuse. If someone is
|
||||
seriously out of control, it's important to be able to deal with this
|
||||
immediately rather than be paralyzed by debate. In all cases, a
|
||||
committer whose privileges are suspended or revoked is entitled to a
|
||||
<quote>hearing</quote>, the total duration of the suspension being
|
||||
determined at that time. A committer whose privileges are suspended may
|
||||
also request a review of the decision after 30 days and every 30 days
|
||||
thereafter (unless the total suspension period is less than 30 days). A
|
||||
committer whose privileges have been revoked entirely may request a
|
||||
review after a period of 6 months have elapsed. This review policy is
|
||||
<emphasis>strictly informal</emphasis> and, in all cases, core reserves
|
||||
the right to either act on or disregard requests for review if they feel
|
||||
their original decision to be the right one.</para>
|
||||
<para>As noted, breaking some of these rules can be grounds for
|
||||
suspension or, upon repeated offense, permanent removal of
|
||||
commit privileges. Three or more members of core, or the
|
||||
Principal Architect and another member of core acting in unison,
|
||||
have the power to temporarily suspend commit privileges until
|
||||
<literal>-core</literal> as a whole has the chance to review the
|
||||
issue. In case of an <quote>emergency</quote> (a committer
|
||||
doing damage to the 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 time. Only core as a whole
|
||||
has the authority to suspend commit privileges for any
|
||||
significant length of time or to remove them permanently, the
|
||||
latter generally only being done after consultation with
|
||||
committers. This rule does not exist to set core up as a bunch
|
||||
of cruel dictators who can dispose of committers as casually as
|
||||
empty soda cans, but to give the project a kind of safety fuse.
|
||||
If someone is seriously out of control, it's important to be
|
||||
able to deal with this immediately rather than be paralyzed by
|
||||
debate. In all cases, a committer whose privileges are
|
||||
suspended or revoked is entitled to a <quote>hearing</quote>,
|
||||
the total duration of the suspension being determined at that
|
||||
time. A committer whose privileges are suspended may also
|
||||
request a review of the decision after 30 days and every 30 days
|
||||
thereafter (unless the total suspension period is less than 30
|
||||
days). A committer whose privileges have been revoked entirely
|
||||
may request a review after a period of 6 months have elapsed.
|
||||
This review policy is <emphasis>strictly informal</emphasis>
|
||||
and, in all cases, core reserves the right to either act on or
|
||||
disregard requests for review if they feel their original
|
||||
decision to be the right one.</para>
|
||||
|
||||
<para>In all other aspects of project operation, core is a subset of
|
||||
committers and is bound by the <emphasis>same rules</emphasis>. Just
|
||||
because someone is in core doesn't mean that they have special
|
||||
dispensation to step outside of any of the lines painted here; core's
|
||||
<quote>special powers</quote> only kick in when it acts as a group, not
|
||||
on an individual basis. As individuals, we are all committers first and
|
||||
core second.</para>
|
||||
<para>In all other aspects of project operation, core is a subset
|
||||
of committers and is bound by the <emphasis>same
|
||||
rules</emphasis>. Just because someone is in core doesn't mean
|
||||
that they have special dispensation to step outside of any of
|
||||
the lines painted here; core's <quote>special powers</quote>
|
||||
only kick in when it acts as a group, not on an individual
|
||||
basis. As individuals, we are all committers first and core
|
||||
second.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Details</title>
|
||||
|
|
@ -547,55 +568,61 @@
|
|||
<listitem>
|
||||
<para>Respect other committers.</para>
|
||||
|
||||
<para>This means that you need to treat other committers as the
|
||||
peer-group developers that they are. Despite our occasional
|
||||
attempts to prove the contrary, one doesn't get into committers by
|
||||
being stupid and nothing rankles more than being treated that way
|
||||
by one of your peers. Whether we always feel respect for one
|
||||
another or not (and everyone has off days), we still have to
|
||||
<emphasis>treat</emphasis> other committers with respect at all
|
||||
times or the whole team structure rapidly breaks down.</para>
|
||||
<para>This means that you need to treat other committers as
|
||||
the peer-group developers that they are. Despite our
|
||||
occasional attempts to prove the contrary, one doesn't get
|
||||
into committers by being stupid and nothing rankles more
|
||||
than being treated that way by one of your peers. Whether
|
||||
we always feel respect for one another or not (and
|
||||
everyone has off days), we still have to
|
||||
<emphasis>treat</emphasis> other committers with respect
|
||||
at all times or the whole team structure rapidly breaks
|
||||
down.</para>
|
||||
|
||||
<para>Being able to work together long term is this project's
|
||||
greatest asset, one far more important than any set of changes to
|
||||
the code, and turning arguments about code into issues that affect
|
||||
our long-term ability to work harmoniously together is just not
|
||||
worth the trade-off by any conceivable stretch of the
|
||||
imagination.</para>
|
||||
greatest asset, one far more important than any set of
|
||||
changes to the code, and turning arguments about code into
|
||||
issues that affect our long-term ability to work
|
||||
harmoniously together is just not worth the trade-off by
|
||||
any conceivable stretch of the imagination.</para>
|
||||
|
||||
<para>To comply with this rule, don't send email when you're angry
|
||||
or otherwise behave in a manner which is likely to strike others
|
||||
as needlessly confrontational. First calm down, then think about
|
||||
how to communicate in the most effective fashion for convincing
|
||||
the other person(s) that your side of the argument is correct,
|
||||
don't just blow off some steam so you can feel better in the short
|
||||
term at the cost of a long-term flame war. Not only is this very
|
||||
bad <quote>energy economics</quote>, but repeated displays of
|
||||
public aggression which impair our ability to work well together
|
||||
will be dealt with severely by the project leadership and may
|
||||
result in suspension or termination of your commit privileges.
|
||||
That's never an option which the project's leadership enjoys in
|
||||
the slightest, but unity comes first. No amount of code or good
|
||||
advice is worth trading that away.</para>
|
||||
<para>To comply with this rule, don't send email when you're
|
||||
angry or otherwise behave in a manner which is likely to
|
||||
strike others as needlessly confrontational. First calm
|
||||
down, then think about how to communicate in the most
|
||||
effective fashion for convincing the other person(s) that
|
||||
your side of the argument is correct, don't just blow off
|
||||
some steam so you can feel better in the short term at the
|
||||
cost of a long-term flame war. Not only is this very bad
|
||||
<quote>energy economics</quote>, but repeated displays of
|
||||
public aggression which impair our ability to work well
|
||||
together will be dealt with severely by the project
|
||||
leadership and may result in suspension or termination of
|
||||
your commit privileges. That's never an option which the
|
||||
project's leadership enjoys in the slightest, but unity
|
||||
comes first. No amount of code or good advice is worth
|
||||
trading that away.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Discuss any significant change <emphasis>before</emphasis>
|
||||
committing.</para>
|
||||
<para>Discuss any significant change
|
||||
<emphasis>before</emphasis> committing.</para>
|
||||
|
||||
<para>The CVS repository is not where changes should be initially
|
||||
submitted for correctness or argued over, that should happen first
|
||||
in the mailing lists and then committed only once something
|
||||
resembling consensus has been reached. This doesn't mean that you
|
||||
have to ask permission before correcting every obvious syntax
|
||||
error or man page misspelling, simply that you should try to
|
||||
develop a feel for when a proposed change isn't quite such a
|
||||
no-brainer and requires some feedback first. People really don't
|
||||
mind sweeping changes if the result is something clearly better
|
||||
than what they had before, they just don't like being
|
||||
<emphasis>surprised</emphasis> by those changes. The very best
|
||||
way of making sure that you're on the right track is to have your
|
||||
code reviewed by one or more other committers.</para>
|
||||
<para>The CVS repository is not where changes should be
|
||||
initially submitted for correctness or argued over, that
|
||||
should happen first in the mailing lists and then
|
||||
committed only once something resembling consensus has
|
||||
been reached. This doesn't mean that you have to ask
|
||||
permission before correcting every obvious syntax error or
|
||||
man page misspelling, simply that you should try to
|
||||
develop a feel for when a proposed change isn't quite such
|
||||
a no-brainer and requires some feedback first. People
|
||||
really don't mind sweeping changes if the result is
|
||||
something clearly better than what they had before, they
|
||||
just don't like being <emphasis>surprised</emphasis> by
|
||||
those changes. The very best way of making sure that
|
||||
you're on the right track is to have your code reviewed by
|
||||
one or more other committers.</para>
|
||||
|
||||
<para>When in doubt, ask for review!</para>
|
||||
</listitem>
|
||||
|
|
@ -603,168 +630,191 @@
|
|||
<listitem>
|
||||
<para>Respect existing maintainers if listed.</para>
|
||||
|
||||
<para>Many parts of FreeBSD aren't <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 is to put a maintainer line in the
|
||||
<filename>Makefile</filename> for any package or subtree which is
|
||||
being actively maintained by one or more people; see <ulink
|
||||
url="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</ulink>
|
||||
for documentation on this. Where sections of code have several
|
||||
maintainers, commits to affected areas by one maintainer need to
|
||||
be reviewed by at least one other maintainer. In cases where the
|
||||
<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
|
||||
been working recently or predominantly in that area.</para>
|
||||
<para>Many parts of FreeBSD aren't <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
|
||||
is to put a maintainer line in the
|
||||
<filename>Makefile</filename> for any package or subtree
|
||||
which is being actively maintained by one or more people;
|
||||
see <ulink
|
||||
url="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</ulink>
|
||||
for documentation on this. Where sections of code have
|
||||
several maintainers, commits to affected areas by one
|
||||
maintainer need to be reviewed by at least one other
|
||||
maintainer. In cases where the
|
||||
<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 been working recently or
|
||||
predominantly in that area.</para>
|
||||
|
||||
<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="http://www.FreeBSD.org/handbook/staff-who.html">http://www.FreeBSD.org/handbook/staff-who.html</ulink> for more information on this.</para>
|
||||
<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="http://www.FreeBSD.org/handbook/staff-who.html">http://www.FreeBSD.org/handbook/staff-who.html</ulink>
|
||||
for more information on this.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Never touch the repository directly. Ask a
|
||||
Repomeister.</para>
|
||||
|
||||
<para>This is pretty clear - you're not allowed to make direct
|
||||
modifications to the CVS repository, period. In case of
|
||||
difficulty, ask one of the repository meisters by sending mail to
|
||||
<email>cvs@FreeBSD.org</email> and simply wait for them to fix the
|
||||
problem and get back to you. Do not attempt to fix the problem
|
||||
yourself!</para>
|
||||
<para>This is pretty clear - you're not allowed to make
|
||||
direct modifications to the CVS repository, period. In
|
||||
case of difficulty, ask one of the repository meisters by
|
||||
sending mail to <email>cvs@FreeBSD.org</email> and simply
|
||||
wait for them to fix the problem and get back to you. Do
|
||||
not attempt to fix the problem yourself!</para>
|
||||
|
||||
<para>If you're thinking about putting down a tag or doing a new
|
||||
import of code on a vendor branch, you might also find it useful
|
||||
to ask for advice first. A lot of people get this wrong the first
|
||||
few times and the consequences are expensive in terms of files
|
||||
touched and angry CVSup/CTM folks who are suddenly getting a lot
|
||||
of changes sent over unnecessarily.</para>
|
||||
<para>If you're thinking about putting down a tag or doing a
|
||||
new import of code on a vendor branch, you might also find
|
||||
it useful to ask for advice first. A lot of people get
|
||||
this wrong the first few times and the consequences are
|
||||
expensive in terms of files touched and angry CVSup/CTM
|
||||
folks who are suddenly getting a lot of changes sent over
|
||||
unnecessarily.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Any disputed change must be backed out pending resolution of
|
||||
the dispute if requested by a maintainer or the Principal
|
||||
Architect. Security related changes may override a maintainer's
|
||||
wishes at the Security Officer's discretion.</para>
|
||||
<para>Any disputed change must be backed out pending
|
||||
resolution of the dispute if requested by a maintainer or
|
||||
the Principal Architect. Security related changes may
|
||||
override a maintainer's wishes at the Security Officer's
|
||||
discretion.</para>
|
||||
|
||||
<para>This may be hard to swallow in times of conflict (when each
|
||||
side is convinced that they're in the right, of course) but CVS
|
||||
makes it unnecessary to have an ongoing dispute raging when it's
|
||||
far easier to simply reverse the disputed change, get everyone
|
||||
calmed down again and then try and figure out how best to proceed.
|
||||
If the change turns out to be the best thing after all, it can be
|
||||
easily brought back. If it turns out not to be, then the users
|
||||
didn't have to live with the bogus change in the tree while
|
||||
everyone was busily debating its merits. People very very rarely
|
||||
call for back-outs in the repository since discussion generally
|
||||
exposes bad or controversial changes before the commit even
|
||||
happens, but on such rare occasions the back-out should be done
|
||||
without argument so that we can get immediately on to the topic of
|
||||
figuring out whether it was bogus or not.</para>
|
||||
<para>This may be hard to swallow in times of conflict (when
|
||||
each side is convinced that they're in the right, of
|
||||
course) but CVS makes it unnecessary to have an ongoing
|
||||
dispute raging when it's far easier to simply reverse the
|
||||
disputed change, get everyone calmed down again and then
|
||||
try and figure out how best to proceed. If the change
|
||||
turns out to be the best thing after all, it can be easily
|
||||
brought back. If it turns out not to be, then the users
|
||||
didn't have to live with the bogus change in the tree
|
||||
while everyone was busily debating its merits. People
|
||||
very very rarely call for back-outs in the repository
|
||||
since discussion generally exposes bad or controversial
|
||||
changes before the commit even happens, but on such rare
|
||||
occasions the back-out should be done without argument so
|
||||
that we can get immediately on to the topic of figuring
|
||||
out whether it was bogus or not.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before <literal>-STABLE</literal> unless specifically
|
||||
permitted by the release engineer or unless they're not applicable
|
||||
to <literal>-CURRENT</literal>. Any non-trivial or non-urgent change which is
|
||||
applicable should also be allowed to sit in <literal>-CURRENT</literal> for at least
|
||||
3 days before merging so that it can be given sufficient testing.
|
||||
The release engineer has the same authority over the <literal>-STABLE</literal>
|
||||
branch as outlined in rule #5.</para>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before
|
||||
<literal>-STABLE</literal> unless specifically permitted
|
||||
by the release engineer or unless they're not applicable
|
||||
to <literal>-CURRENT</literal>. Any non-trivial or
|
||||
non-urgent change which is applicable should also be
|
||||
allowed to sit in <literal>-CURRENT</literal> for at least
|
||||
3 days before merging so that it can be given sufficient
|
||||
testing. The release engineer has the same authority over
|
||||
the <literal>-STABLE</literal> branch as outlined in rule
|
||||
#5.</para>
|
||||
|
||||
<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
|
||||
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
|
||||
<literal>-STABLE</literal> branch. The management of <literal>-STABLE</literal> may frequently seem to
|
||||
be overly conservative to the casual observer, but also bear in
|
||||
mind the fact that conservatism is supposed to be the hallmark of
|
||||
<literal>-STABLE</literal> and different rules apply there than in <literal>-CURRENT</literal>. There's
|
||||
also really no point in having <literal>-CURRENT</literal> be a testing ground if
|
||||
changes are merged over to <literal>-STABLE</literal> immediately. Changes need
|
||||
a chance to be tested by the <literal>-CURRENT</literal> developers, so allow some
|
||||
time to elapse before merging unless the <literal>-STABLE</literal> fix is critical,
|
||||
<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 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
|
||||
<literal>-STABLE</literal> branch. The management of
|
||||
<literal>-STABLE</literal> may frequently seem to be
|
||||
overly conservative to the casual observer, but also bear
|
||||
in mind the fact that conservatism is supposed to be the
|
||||
hallmark of <literal>-STABLE</literal> and different rules
|
||||
apply there than in <literal>-CURRENT</literal>. There's
|
||||
also really no point in having <literal>-CURRENT</literal>
|
||||
be a testing ground if changes are merged over to
|
||||
<literal>-STABLE</literal> immediately. Changes need a
|
||||
chance to be tested by the <literal>-CURRENT</literal>
|
||||
developers, so allow some time to elapse before merging
|
||||
unless the <literal>-STABLE</literal> fix is critical,
|
||||
time sensitive or so obvious as to make further testing
|
||||
unnecessary (spelling fixes to manpages, obvious bug/typo fixes,
|
||||
etc.) In other words, apply common sense.</para>
|
||||
unnecessary (spelling fixes to manpages, obvious bug/typo
|
||||
fixes, etc.) In other words, apply common sense.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't fight in public with other committers; it looks bad. If
|
||||
you must <quote>strongly disagree</quote> about something, do so
|
||||
only in private.</para>
|
||||
<para>Don't fight in public with other committers; it looks
|
||||
bad. If you must <quote>strongly disagree</quote> about
|
||||
something, do so only in private.</para>
|
||||
|
||||
<para>This project has a public image to uphold and that image is
|
||||
very important to all of us, especially if we are to continue to
|
||||
attract new members. There will be occasions when, despite
|
||||
everyone's very best attempts at self-control, tempers are lost
|
||||
and angry words are exchanged, and the best we can do is try and
|
||||
minimize the effects of this until everyone has cooled back down.
|
||||
That means that you should not air your angry words in public and
|
||||
you should not forward private correspondence to public mailing
|
||||
lists or aliases. What people say one-to-one is often much less
|
||||
sugar-coated than what they would say in public, and such
|
||||
communications therefore have no place there - they only serve to
|
||||
inflame an already bad situation. If the person sending you a
|
||||
flame-o-gram at least had the grace to send it privately, then
|
||||
have the grace to keep it private yourself. If you feel you are
|
||||
being unfairly treated by another developer, and it is causing you
|
||||
anguish, bring the matter up with core rather than taking it
|
||||
public. We will do our best to play peace makers and get things
|
||||
back to sanity. In cases where the dispute involves a change to
|
||||
the codebase and the participants do not appear to be reaching an
|
||||
amicable agreement, core may appoint a mutually-agreeable 3rd
|
||||
party to resolve the dispute. All parties involved must then
|
||||
<para>This project has a public image to uphold and that
|
||||
image is very important to all of us, especially if we are
|
||||
to continue to attract new members. There will be
|
||||
occasions when, despite everyone's very best attempts at
|
||||
self-control, tempers are lost and angry words are
|
||||
exchanged, and the best we can do is try and minimize the
|
||||
effects of this until everyone has cooled back down. That
|
||||
means that you should not air your angry words in public
|
||||
and you should not forward private correspondence to
|
||||
public mailing lists or aliases. What people say
|
||||
one-to-one is often much less sugar-coated than what they
|
||||
would say in public, and such communications therefore
|
||||
have no place there - they only serve to inflame an
|
||||
already bad situation. If the person sending you a
|
||||
flame-o-gram at least had the grace to send it privately,
|
||||
then have the grace to keep it private yourself. If you
|
||||
feel you are being unfairly treated by another developer,
|
||||
and it is causing you anguish, bring the matter up with
|
||||
core rather than taking it public. We will do our best to
|
||||
play peace makers and get things back to sanity. In cases
|
||||
where the dispute involves a change to the codebase and
|
||||
the participants do not appear to be reaching an amicable
|
||||
agreement, core may appoint a mutually-agreeable 3rd party
|
||||
to resolve the dispute. All parties involved must then
|
||||
agree to be bound by the decision reached by this 3rd
|
||||
party.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Respect all code freezes and read the <literal>committers</literal> mailing list
|
||||
on a timely basis so you know when they are.</para>
|
||||
<para>Respect all code freezes and read the
|
||||
<literal>committers</literal> mailing list on a timely
|
||||
basis so you know when they are.</para>
|
||||
|
||||
<para>Committing changes during a code freeze is a really big
|
||||
mistake and committers are expected to keep up-to-date on what's
|
||||
going on before jumping in after a long absence 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 FreeBSD Happy Reeducation Camp we run in
|
||||
Greenland.</para>
|
||||
<para>Committing changes during a code freeze is a really
|
||||
big mistake and committers are expected to keep up-to-date
|
||||
on what's going on before jumping in after a long absence
|
||||
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
|
||||
FreeBSD Happy Reeducation Camp we run in Greenland.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>When in doubt on any procedure, ask first!</para>
|
||||
|
||||
<para>Many mistakes are made because someone is in a hurry and
|
||||
just assumes they know the right way of doing something. If
|
||||
you have not done it before, chances are good that you do not
|
||||
actually know the way we do things and really need to ask first or
|
||||
you are going to completely embarrass yourself in public. There's
|
||||
no shame in asking <quote>how in the heck do I do this?</quote>
|
||||
We already know you are an intelligent person; otherwise, you would not be a
|
||||
committer.</para>
|
||||
<para>Many mistakes are made because someone is in a hurry
|
||||
and just assumes they know the right way of doing
|
||||
something. If you have not done it before, chances are
|
||||
good that you do not actually know the way we do things
|
||||
and really need to ask first or you are going to
|
||||
completely embarrass yourself in public. There's no shame
|
||||
in asking <quote>how in the heck do I do this?</quote> We
|
||||
already know you are an intelligent person; otherwise, you
|
||||
would not be a committer.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Test your changes before committing them.</para>
|
||||
|
||||
<para>This may sound obvious, but if it really were so obvious then
|
||||
we probably wouldn't see so many cases of people clearly not doing
|
||||
this. If your changes are to the kernel, make sure you can still
|
||||
compile both GENERIC and LINT. If your changes are anywhere else,
|
||||
make sure you can still make world. If your changes are to a
|
||||
branch, make sure your testing occurs with a machine which is
|
||||
running that code. If you have a change which also may break
|
||||
another architecture, be sure and test on all supported
|
||||
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
|
||||
account on <hostid role="fqdn">beast.FreeBSD.org</hostid> will let
|
||||
you compile and test alpha binaries/kernels/etc. As other
|
||||
architectures are added to the FreeBSD supported platforms list,
|
||||
the appropriate shared testing resources will be made
|
||||
available.</para>
|
||||
<para>This may sound obvious, but if it really were so
|
||||
obvious then we probably wouldn't see so many cases of
|
||||
people clearly not doing this. If your changes are to the
|
||||
kernel, make sure you can still compile both GENERIC and
|
||||
LINT. If your changes are anywhere else, make sure you
|
||||
can still make world. If your changes are to a branch,
|
||||
make sure your testing occurs with a machine which is
|
||||
running that code. If you have a change which also may
|
||||
break another architecture, be sure and test on all
|
||||
supported 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 account on <hostid
|
||||
role="fqdn">beast.FreeBSD.org</hostid> will let you
|
||||
compile and test alpha binaries/kernels/etc. As other
|
||||
architectures are added to the FreeBSD supported platforms
|
||||
list, the appropriate shared testing resources will be
|
||||
made available.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
|
@ -772,26 +822,27 @@
|
|||
<sect2>
|
||||
<title>Other Suggestions</title>
|
||||
|
||||
<para>When committing documentation changes, use a
|
||||
spell checker before committing. :) For all SGML docs, you should
|
||||
also verify that your formatting directives are correct by running
|
||||
<para>When committing documentation changes, use a spell checker
|
||||
before committing. :) For all SGML docs, you should also
|
||||
verify that your formatting directives are correct by running
|
||||
<command>make lint</command>.</para>
|
||||
|
||||
<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
|
||||
are correct and that the man page has all of the appropriate
|
||||
<makevar>MLINK</makevar>s installed.</para>
|
||||
<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 are correct and that the man
|
||||
page has all of the appropriate <makevar>MLINK</makevar>s
|
||||
installed.</para>
|
||||
|
||||
<para>Do not mix style fixes with new functionality. A style
|
||||
fix is any change which does not modify the functionality of
|
||||
the code. Mixing the changes ofucsates the functionality
|
||||
change when using <command>cvs diff</command>, which can hide
|
||||
any new bugs. Do not
|
||||
include whitespace changes with content changes in commits to
|
||||
<filename>doc/</filename> or <filename>www/</filename>. The extra clutter in the diffs
|
||||
makes the translators' job much more difficult. Instead, make any
|
||||
style or whitespace changes in seperate commits that are clearly
|
||||
labeled as such in the commit message.</para>
|
||||
any new bugs. Do not include whitespace changes with content
|
||||
changes in commits to <filename>doc/</filename> or
|
||||
<filename>www/</filename>. The extra clutter in the diffs
|
||||
makes the translators' job much more difficult. Instead, make
|
||||
any style or whitespace changes in seperate commits that are
|
||||
clearly labeled as such in the commit message.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -815,9 +866,10 @@
|
|||
<command>easy-import</command> script on
|
||||
<hostid>freefall</hostid>. It will ask you some
|
||||
questions and import the port in the directory you
|
||||
specify. It will also add an entry to the <filename>CVSROOT/modules</filename>
|
||||
file. It was written by &a.joerg; so please send mail
|
||||
to him if you have questions about
|
||||
specify. It will also add an entry to the
|
||||
<filename>CVSROOT/modules</filename> file. It was
|
||||
written by &a.joerg; so please send mail to him if you
|
||||
have questions about
|
||||
<command>easy-import</command>.</para>
|
||||
|
||||
<para>One thing it will not do for you is add the port to
|
||||
|
|
@ -857,8 +909,8 @@
|
|||
|
||||
<para>If the port came from a submitter who has not
|
||||
contributed to the project before, add that person's
|
||||
name to the Handbook's
|
||||
<citetitle pubwork="section">Additional Contributors</citetitle>
|
||||
name to the Handbook's <citetitle
|
||||
pubwork="section">Additional Contributors</citetitle>
|
||||
section.</para>
|
||||
|
||||
<para>Close the PR if the port came in as a PR. To close
|
||||
|
|
@ -1024,17 +1076,19 @@
|
|||
<answer>
|
||||
<para>The ports manager will send out warning messages to
|
||||
the <email>freebsd-ports@FreeBSD.org</email> and
|
||||
<email>cvs-committers@FreeBSD.org</email> mailing lists announcing
|
||||
the start of the impending release, usually two or three
|
||||
weeks in advance. The exact starting time will not be
|
||||
determined until a few days before the actual release.
|
||||
This is because the ports freeze has to be synchronized
|
||||
with the release, and it is usually not known until then
|
||||
when exactly the release will be rolled.</para>
|
||||
<email>cvs-committers@FreeBSD.org</email> mailing lists
|
||||
announcing the start of the impending release, usually
|
||||
two or three weeks in advance. The exact starting time
|
||||
will not be determined until a few days before the
|
||||
actual release. This is because the ports freeze has to
|
||||
be synchronized with the release, and it is usually not
|
||||
known until then when exactly the release will be
|
||||
rolled.</para>
|
||||
|
||||
<para>When the freeze starts, there will be another
|
||||
announcement to the <email>cvs-committers@FreeBSD.org</email>
|
||||
list, of course.</para>
|
||||
announcement to the
|
||||
<email>cvs-committers@FreeBSD.org</email> list, of
|
||||
course.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -1046,8 +1100,8 @@
|
|||
<answer>
|
||||
<para>A few hours after the release, the ports manager
|
||||
will send out a mail to the
|
||||
<email>freebsd-ports@FreeBSD.org</email> and
|
||||
<email>cvs-committers@FreeBSD.org</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
|
||||
release being cut does not automatically end the freeze.
|
||||
We have to make sure there will not be any last minute
|
||||
|
|
@ -1147,14 +1201,16 @@
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>The RCS file format is quite braindead and certain operations
|
||||
to achieve things for CVS are hideously expensive for the
|
||||
repository. Making changes to files on a vendor branch, thereby
|
||||
pulling the file off that branch, is one example of this.</para>
|
||||
<para>The RCS file format is quite braindead and certain
|
||||
operations to achieve things for CVS are hideously
|
||||
expensive for the repository. Making changes to files on
|
||||
a vendor branch, thereby pulling the file off that branch,
|
||||
is one example of this.</para>
|
||||
|
||||
<para>Suppose you have a file which was first imported on a vendor
|
||||
branch, and was then re-imported three times (still on the vendor
|
||||
branch) as the vendor makes updates to the file.</para>
|
||||
<para>Suppose you have a file which was first imported on a
|
||||
vendor branch, and was then re-imported three times (still
|
||||
on the vendor branch) as the vendor makes updates to the
|
||||
file.</para>
|
||||
|
||||
<segmentedlist>
|
||||
<seglistitem>
|
||||
|
|
@ -1178,21 +1234,25 @@
|
|||
</seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<para>Now suppose that one of the FreeBSD committers makes a one
|
||||
line change to this file, causing it to go to version 1.2. This
|
||||
causes it to leave the branch, resulting in 4,001 lines being added
|
||||
to the file's history, and 2,001 lines being deleted.</para>
|
||||
<para>Now suppose that one of the FreeBSD committers makes a
|
||||
one line change to this file, causing it to go to version
|
||||
1.2. This causes it to leave the branch, resulting in
|
||||
4,001 lines being added to the file's history, and 2,001
|
||||
lines being deleted.</para>
|
||||
|
||||
<para>This is because the 1.2 delta is stored relative to 1.1.1.1,
|
||||
<emphasis>not</emphasis> 1.1.1.4, and so the entire vendor history
|
||||
is duplicated in the 1.2 delta. Now, repeat this for 2000 files
|
||||
in a large directory, it adds up a lot.</para>
|
||||
<para>This is because the 1.2 delta is stored relative to
|
||||
1.1.1.1, <emphasis>not</emphasis> 1.1.1.4, and so the
|
||||
entire vendor history is duplicated in the 1.2 delta.
|
||||
Now, repeat this for 2000 files in a large directory, it
|
||||
adds up a lot.</para>
|
||||
|
||||
<para><emphasis>This</emphasis> is why we have such <quote>hands
|
||||
off</quote> policies for <filename>src/contrib</filename> and other things that track
|
||||
the vendor releases. This is why <quote>typo fixes</quote> in man
|
||||
pages and spelling <quote>corrections</quote> are so strongly
|
||||
discouraged for vendor code.</para>
|
||||
<para><emphasis>This</emphasis> is why we have such
|
||||
<quote>hands off</quote> policies for
|
||||
<filename>src/contrib</filename> and other things that
|
||||
track the vendor releases. This is why <quote>typo
|
||||
fixes</quote> in man pages and spelling
|
||||
<quote>corrections</quote> are so strongly discouraged for
|
||||
vendor code.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
</qandaset>
|
||||
|
|
|
|||
|
|
@ -185,10 +185,13 @@
|
|||
(where <replaceable>user</replaceable> is your username) file
|
||||
containing the e-mail address where you want mail addressed
|
||||
to <replaceable>yourusername</replaceable>@FreeBSD.org
|
||||
to be forwarded. This includes all of the commit messages as well as any other mail addressed to <email>cvs-committers@FreeBSD.org</email>. Really large mailboxes which have taken up
|
||||
permanent residence on <hostid>hub</hostid> often get
|
||||
<quote>accidently</quote> truncated without warning, so forward
|
||||
it or read it and you will not lose it.</para>
|
||||
to be forwarded. This includes all of the commit messages as
|
||||
well as any other mail addressed to
|
||||
<email>cvs-committers@FreeBSD.org</email>. Really large
|
||||
mailboxes which have taken up permanent residence on
|
||||
<hostid>hub</hostid> often get <quote>accidently</quote>
|
||||
truncated without warning, so forward it or read it and you will
|
||||
not lose it.</para>
|
||||
|
||||
<para>All new committers also have a mentor assigned to them for
|
||||
the first few months. Your mentor is more or less responsible for
|
||||
|
|
@ -216,15 +219,20 @@
|
|||
areas, to our shame), the same applies. If, however, you are
|
||||
about to modify something which is clearly being actively
|
||||
maintained by someone else (and it is only by watching the
|
||||
<literal>cvs-committers</literal> mailing list that you can really get
|
||||
a feel for just what is and is not) then consider sending the
|
||||
change to them instead, just as you would have before becoming a
|
||||
committer. For ports, you should contact the listed
|
||||
<makevar>MAINTAINER</makevar> in the
|
||||
<literal>cvs-committers</literal> mailing list that you can
|
||||
really get a feel for just what is and is not) then consider
|
||||
sending the change to them instead, just as you would have
|
||||
before becoming a committer. For ports, you should contact the
|
||||
listed <makevar>MAINTAINER</makevar> in the
|
||||
<filename>Makefile</filename>. For other parts of the
|
||||
repository, if you are unsure who the active maintainer might
|
||||
be, it may help to scan the output of <command>cvs log</command>
|
||||
to see who has committed changes in the past. &a.fenner; has written a nice shell script that can help determine who the active maintainer might be. It lists each person who has committed to a given file along with the number of commits each person has made. It can be found on <hostid>freefall</hostid> at <filename>~fenner/bin/whodid</filename>. If your queries go
|
||||
to see who has committed changes in the past. &a.fenner; has
|
||||
written a nice shell script that can help determine who the
|
||||
active maintainer might be. It lists each person who has
|
||||
committed to a given file along with the number of commits each
|
||||
person has made. It can be found on <hostid>freefall</hostid>
|
||||
at <filename>~fenner/bin/whodid</filename>. If your queries go
|
||||
unanswered or the committer otherwise indicates a lack of
|
||||
proprietary interest in the area affected, go ahead and commit
|
||||
it.</para>
|
||||
|
|
@ -289,10 +297,11 @@
|
|||
<term>&a.asami;</term>
|
||||
|
||||
<listitem>
|
||||
<para>Satoshi is the Ports Wraith, meaning that he has ultimate
|
||||
authority over any modifications to the ports collection or
|
||||
the ports skeleton makefiles. He is also the one responsible for
|
||||
administering code freezes before the releases.</para>
|
||||
<para>Satoshi is the Ports Wraith, meaning that he has
|
||||
ultimate authority over any modifications to the ports
|
||||
collection or the ports skeleton makefiles. He is also
|
||||
the one responsible for administering code freezes before
|
||||
the releases.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -300,9 +309,9 @@
|
|||
<term>&a.bde;</term>
|
||||
|
||||
<listitem>
|
||||
<para>Bruce is the Obersturmbahnfuhrer of the Style Police. When you
|
||||
do a commit that could have been done better, Bruce will
|
||||
be there to tell you. Be thankful that someone
|
||||
<para>Bruce is the Obersturmbahnfuhrer of the Style Police.
|
||||
When you do a commit that could have been done better,
|
||||
Bruce will be there to tell you. Be thankful that someone
|
||||
is.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
@ -311,14 +320,13 @@
|
|||
<term>&a.dg;</term>
|
||||
|
||||
<listitem>
|
||||
<para>David is our principal architect and overseer of the VM
|
||||
system. If you have a VM system change in mind,
|
||||
<para>David is our principal architect and overseer of the
|
||||
VM system. If you have a VM system change in mind,
|
||||
coordinate it with David. Should you become locked in a
|
||||
bitter, intractable dispute with some other committer over
|
||||
a proposed change (which does not happen very often,
|
||||
thankfully) then an appeal to David to put on his P.A. hat
|
||||
and make a final decision might be
|
||||
necessary.</para>
|
||||
and make a final decision might be necessary.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
@ -399,14 +407,15 @@
|
|||
</step>
|
||||
|
||||
<step>
|
||||
<para>If you do not wish to to type your password in every time
|
||||
you use &man.ssh.1;, and you use RSA keys to authenticate,
|
||||
&man.ssh-agent.1; is there for your convenience. If
|
||||
you want to use &man.ssh-agent.1;, make sure that you run it
|
||||
before running other applications. X users, for example,
|
||||
usually do this from their <filename>.xsession</filename> or
|
||||
<filename>.xinitrc</filename> file.
|
||||
See &man.ssh-agent.1; for details.</para>
|
||||
<para>If you do not wish to to type your password in every
|
||||
time you use &man.ssh.1;, and you use RSA keys to
|
||||
authenticate, &man.ssh-agent.1; is there for your
|
||||
convenience. If you want to use &man.ssh-agent.1;, make
|
||||
sure that you run it before running other applications. X
|
||||
users, for example, usually do this from their
|
||||
<filename>.xsession</filename> or
|
||||
<filename>.xinitrc</filename> file. See &man.ssh-agent.1;
|
||||
for details.</para>
|
||||
</step>
|
||||
|
||||
<step>
|
||||
|
|
@ -453,47 +462,54 @@
|
|||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Discuss any significant change <emphasis>before</emphasis>
|
||||
committing.</para>
|
||||
<para>Discuss any significant change
|
||||
<emphasis>before</emphasis> committing.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Respect existing maintainers if listed in the
|
||||
(<makevar>MAINTAINER</makevar> field in
|
||||
<filename>Makefile</filename> or in the <filename>MAINTAINER</filename>
|
||||
file in the top-level directory).</para>
|
||||
<filename>Makefile</filename> or in the
|
||||
<filename>MAINTAINER</filename> file in the top-level
|
||||
directory).</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Never touch the repository directly. Ask a Repomeister.</para>
|
||||
<para>Never touch the repository directly. Ask a
|
||||
Repomeister.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Any disputed change must be backed out pending resolution of
|
||||
the dispute if requested by a maintainer or the Principal
|
||||
Architect. Security related changes may override a maintainer's
|
||||
wishes at the Security Officer's discretion.</para>
|
||||
<para>Any disputed change must be backed out pending
|
||||
resolution of the dispute if requested by a maintainer or
|
||||
the Principal Architect. Security related changes may
|
||||
override a maintainer's wishes at the Security Officer's
|
||||
discretion.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before <literal>-STABLE</literal> unless specifically
|
||||
permitted by the release engineer or unless they're not applicable
|
||||
to <literal>-CURRENT</literal>. Any non-trivial or non-urgent change which is
|
||||
applicable should also be allowed to sit in <literal>-CURRENT</literal> for at least 3
|
||||
days before merging so that it can be given sufficient testing. The
|
||||
release engineer has the same authority over the <literal>-STABLE</literal> branch as
|
||||
outlined for the Principal Architect in rule #5.</para>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before
|
||||
<literal>-STABLE</literal> unless specifically permitted by
|
||||
the release engineer or unless they're not applicable to
|
||||
<literal>-CURRENT</literal>. Any non-trivial or non-urgent
|
||||
change which is applicable should also be allowed to sit in
|
||||
<literal>-CURRENT</literal> for at least 3 days before
|
||||
merging so that it can be given sufficient testing. The
|
||||
release engineer has the same authority over the
|
||||
<literal>-STABLE</literal> branch as outlined for the
|
||||
Principal Architect in rule #5.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't fight in public with other committers; it looks bad. If
|
||||
you must <quote>strongly disagree</quote> about something, do so only in
|
||||
private.</para>
|
||||
<para>Don't fight in public with other committers; it looks
|
||||
bad. If you must <quote>strongly disagree</quote> about
|
||||
something, do so only in private.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Respect all code freezes and read the <literal>committers</literal> mailing list on
|
||||
a timely basis so you know when a code freeze is in effect.</para>
|
||||
<para>Respect all code freezes and read the
|
||||
<literal>committers</literal> mailing list on a timely basis
|
||||
so you know when a code freeze is in effect.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
|
|
@ -505,40 +521,45 @@
|
|||
</listitem>
|
||||
</orderedlist>
|
||||
|
||||
<para>As noted, breaking some of these rules can be grounds for suspension
|
||||
or, upon repeated offense, permanent removal of commit privileges.
|
||||
Three or more members of core, or the Principal Architect and another
|
||||
member of core acting in unison, have the power to temporarily suspend
|
||||
commit privileges until <literal>-core</literal> as a whole has the chance to review the
|
||||
issue. In case of an <quote>emergency</quote> (a committer doing damage to the
|
||||
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
|
||||
time. Only core as a whole has the authority to suspend commit
|
||||
privileges for any significant length of time or to remove them
|
||||
permanently, the latter generally only being done after consultation
|
||||
with committers. This rule does not exist to set core up as a bunch of
|
||||
cruel dictators who can dispose of committers as casually as empty soda
|
||||
cans, but to give the project a kind of safety fuse. If someone is
|
||||
seriously out of control, it's important to be able to deal with this
|
||||
immediately rather than be paralyzed by debate. In all cases, a
|
||||
committer whose privileges are suspended or revoked is entitled to a
|
||||
<quote>hearing</quote>, the total duration of the suspension being
|
||||
determined at that time. A committer whose privileges are suspended may
|
||||
also request a review of the decision after 30 days and every 30 days
|
||||
thereafter (unless the total suspension period is less than 30 days). A
|
||||
committer whose privileges have been revoked entirely may request a
|
||||
review after a period of 6 months have elapsed. This review policy is
|
||||
<emphasis>strictly informal</emphasis> and, in all cases, core reserves
|
||||
the right to either act on or disregard requests for review if they feel
|
||||
their original decision to be the right one.</para>
|
||||
<para>As noted, breaking some of these rules can be grounds for
|
||||
suspension or, upon repeated offense, permanent removal of
|
||||
commit privileges. Three or more members of core, or the
|
||||
Principal Architect and another member of core acting in unison,
|
||||
have the power to temporarily suspend commit privileges until
|
||||
<literal>-core</literal> as a whole has the chance to review the
|
||||
issue. In case of an <quote>emergency</quote> (a committer
|
||||
doing damage to the 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 time. Only core as a whole
|
||||
has the authority to suspend commit privileges for any
|
||||
significant length of time or to remove them permanently, the
|
||||
latter generally only being done after consultation with
|
||||
committers. This rule does not exist to set core up as a bunch
|
||||
of cruel dictators who can dispose of committers as casually as
|
||||
empty soda cans, but to give the project a kind of safety fuse.
|
||||
If someone is seriously out of control, it's important to be
|
||||
able to deal with this immediately rather than be paralyzed by
|
||||
debate. In all cases, a committer whose privileges are
|
||||
suspended or revoked is entitled to a <quote>hearing</quote>,
|
||||
the total duration of the suspension being determined at that
|
||||
time. A committer whose privileges are suspended may also
|
||||
request a review of the decision after 30 days and every 30 days
|
||||
thereafter (unless the total suspension period is less than 30
|
||||
days). A committer whose privileges have been revoked entirely
|
||||
may request a review after a period of 6 months have elapsed.
|
||||
This review policy is <emphasis>strictly informal</emphasis>
|
||||
and, in all cases, core reserves the right to either act on or
|
||||
disregard requests for review if they feel their original
|
||||
decision to be the right one.</para>
|
||||
|
||||
<para>In all other aspects of project operation, core is a subset of
|
||||
committers and is bound by the <emphasis>same rules</emphasis>. Just
|
||||
because someone is in core doesn't mean that they have special
|
||||
dispensation to step outside of any of the lines painted here; core's
|
||||
<quote>special powers</quote> only kick in when it acts as a group, not
|
||||
on an individual basis. As individuals, we are all committers first and
|
||||
core second.</para>
|
||||
<para>In all other aspects of project operation, core is a subset
|
||||
of committers and is bound by the <emphasis>same
|
||||
rules</emphasis>. Just because someone is in core doesn't mean
|
||||
that they have special dispensation to step outside of any of
|
||||
the lines painted here; core's <quote>special powers</quote>
|
||||
only kick in when it acts as a group, not on an individual
|
||||
basis. As individuals, we are all committers first and core
|
||||
second.</para>
|
||||
|
||||
<sect2>
|
||||
<title>Details</title>
|
||||
|
|
@ -547,55 +568,61 @@
|
|||
<listitem>
|
||||
<para>Respect other committers.</para>
|
||||
|
||||
<para>This means that you need to treat other committers as the
|
||||
peer-group developers that they are. Despite our occasional
|
||||
attempts to prove the contrary, one doesn't get into committers by
|
||||
being stupid and nothing rankles more than being treated that way
|
||||
by one of your peers. Whether we always feel respect for one
|
||||
another or not (and everyone has off days), we still have to
|
||||
<emphasis>treat</emphasis> other committers with respect at all
|
||||
times or the whole team structure rapidly breaks down.</para>
|
||||
<para>This means that you need to treat other committers as
|
||||
the peer-group developers that they are. Despite our
|
||||
occasional attempts to prove the contrary, one doesn't get
|
||||
into committers by being stupid and nothing rankles more
|
||||
than being treated that way by one of your peers. Whether
|
||||
we always feel respect for one another or not (and
|
||||
everyone has off days), we still have to
|
||||
<emphasis>treat</emphasis> other committers with respect
|
||||
at all times or the whole team structure rapidly breaks
|
||||
down.</para>
|
||||
|
||||
<para>Being able to work together long term is this project's
|
||||
greatest asset, one far more important than any set of changes to
|
||||
the code, and turning arguments about code into issues that affect
|
||||
our long-term ability to work harmoniously together is just not
|
||||
worth the trade-off by any conceivable stretch of the
|
||||
imagination.</para>
|
||||
greatest asset, one far more important than any set of
|
||||
changes to the code, and turning arguments about code into
|
||||
issues that affect our long-term ability to work
|
||||
harmoniously together is just not worth the trade-off by
|
||||
any conceivable stretch of the imagination.</para>
|
||||
|
||||
<para>To comply with this rule, don't send email when you're angry
|
||||
or otherwise behave in a manner which is likely to strike others
|
||||
as needlessly confrontational. First calm down, then think about
|
||||
how to communicate in the most effective fashion for convincing
|
||||
the other person(s) that your side of the argument is correct,
|
||||
don't just blow off some steam so you can feel better in the short
|
||||
term at the cost of a long-term flame war. Not only is this very
|
||||
bad <quote>energy economics</quote>, but repeated displays of
|
||||
public aggression which impair our ability to work well together
|
||||
will be dealt with severely by the project leadership and may
|
||||
result in suspension or termination of your commit privileges.
|
||||
That's never an option which the project's leadership enjoys in
|
||||
the slightest, but unity comes first. No amount of code or good
|
||||
advice is worth trading that away.</para>
|
||||
<para>To comply with this rule, don't send email when you're
|
||||
angry or otherwise behave in a manner which is likely to
|
||||
strike others as needlessly confrontational. First calm
|
||||
down, then think about how to communicate in the most
|
||||
effective fashion for convincing the other person(s) that
|
||||
your side of the argument is correct, don't just blow off
|
||||
some steam so you can feel better in the short term at the
|
||||
cost of a long-term flame war. Not only is this very bad
|
||||
<quote>energy economics</quote>, but repeated displays of
|
||||
public aggression which impair our ability to work well
|
||||
together will be dealt with severely by the project
|
||||
leadership and may result in suspension or termination of
|
||||
your commit privileges. That's never an option which the
|
||||
project's leadership enjoys in the slightest, but unity
|
||||
comes first. No amount of code or good advice is worth
|
||||
trading that away.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Discuss any significant change <emphasis>before</emphasis>
|
||||
committing.</para>
|
||||
<para>Discuss any significant change
|
||||
<emphasis>before</emphasis> committing.</para>
|
||||
|
||||
<para>The CVS repository is not where changes should be initially
|
||||
submitted for correctness or argued over, that should happen first
|
||||
in the mailing lists and then committed only once something
|
||||
resembling consensus has been reached. This doesn't mean that you
|
||||
have to ask permission before correcting every obvious syntax
|
||||
error or man page misspelling, simply that you should try to
|
||||
develop a feel for when a proposed change isn't quite such a
|
||||
no-brainer and requires some feedback first. People really don't
|
||||
mind sweeping changes if the result is something clearly better
|
||||
than what they had before, they just don't like being
|
||||
<emphasis>surprised</emphasis> by those changes. The very best
|
||||
way of making sure that you're on the right track is to have your
|
||||
code reviewed by one or more other committers.</para>
|
||||
<para>The CVS repository is not where changes should be
|
||||
initially submitted for correctness or argued over, that
|
||||
should happen first in the mailing lists and then
|
||||
committed only once something resembling consensus has
|
||||
been reached. This doesn't mean that you have to ask
|
||||
permission before correcting every obvious syntax error or
|
||||
man page misspelling, simply that you should try to
|
||||
develop a feel for when a proposed change isn't quite such
|
||||
a no-brainer and requires some feedback first. People
|
||||
really don't mind sweeping changes if the result is
|
||||
something clearly better than what they had before, they
|
||||
just don't like being <emphasis>surprised</emphasis> by
|
||||
those changes. The very best way of making sure that
|
||||
you're on the right track is to have your code reviewed by
|
||||
one or more other committers.</para>
|
||||
|
||||
<para>When in doubt, ask for review!</para>
|
||||
</listitem>
|
||||
|
|
@ -603,168 +630,191 @@
|
|||
<listitem>
|
||||
<para>Respect existing maintainers if listed.</para>
|
||||
|
||||
<para>Many parts of FreeBSD aren't <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 is to put a maintainer line in the
|
||||
<filename>Makefile</filename> for any package or subtree which is
|
||||
being actively maintained by one or more people; see <ulink
|
||||
url="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</ulink>
|
||||
for documentation on this. Where sections of code have several
|
||||
maintainers, commits to affected areas by one maintainer need to
|
||||
be reviewed by at least one other maintainer. In cases where the
|
||||
<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
|
||||
been working recently or predominantly in that area.</para>
|
||||
<para>Many parts of FreeBSD aren't <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
|
||||
is to put a maintainer line in the
|
||||
<filename>Makefile</filename> for any package or subtree
|
||||
which is being actively maintained by one or more people;
|
||||
see <ulink
|
||||
url="http://www.FreeBSD.org/handbook/policies.html">http://www.FreeBSD.org/handbook/policies.html</ulink>
|
||||
for documentation on this. Where sections of code have
|
||||
several maintainers, commits to affected areas by one
|
||||
maintainer need to be reviewed by at least one other
|
||||
maintainer. In cases where the
|
||||
<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 been working recently or
|
||||
predominantly in that area.</para>
|
||||
|
||||
<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="http://www.FreeBSD.org/handbook/staff-who.html">http://www.FreeBSD.org/handbook/staff-who.html</ulink> for more information on this.</para>
|
||||
<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="http://www.FreeBSD.org/handbook/staff-who.html">http://www.FreeBSD.org/handbook/staff-who.html</ulink>
|
||||
for more information on this.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Never touch the repository directly. Ask a
|
||||
Repomeister.</para>
|
||||
|
||||
<para>This is pretty clear - you're not allowed to make direct
|
||||
modifications to the CVS repository, period. In case of
|
||||
difficulty, ask one of the repository meisters by sending mail to
|
||||
<email>cvs@FreeBSD.org</email> and simply wait for them to fix the
|
||||
problem and get back to you. Do not attempt to fix the problem
|
||||
yourself!</para>
|
||||
<para>This is pretty clear - you're not allowed to make
|
||||
direct modifications to the CVS repository, period. In
|
||||
case of difficulty, ask one of the repository meisters by
|
||||
sending mail to <email>cvs@FreeBSD.org</email> and simply
|
||||
wait for them to fix the problem and get back to you. Do
|
||||
not attempt to fix the problem yourself!</para>
|
||||
|
||||
<para>If you're thinking about putting down a tag or doing a new
|
||||
import of code on a vendor branch, you might also find it useful
|
||||
to ask for advice first. A lot of people get this wrong the first
|
||||
few times and the consequences are expensive in terms of files
|
||||
touched and angry CVSup/CTM folks who are suddenly getting a lot
|
||||
of changes sent over unnecessarily.</para>
|
||||
<para>If you're thinking about putting down a tag or doing a
|
||||
new import of code on a vendor branch, you might also find
|
||||
it useful to ask for advice first. A lot of people get
|
||||
this wrong the first few times and the consequences are
|
||||
expensive in terms of files touched and angry CVSup/CTM
|
||||
folks who are suddenly getting a lot of changes sent over
|
||||
unnecessarily.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Any disputed change must be backed out pending resolution of
|
||||
the dispute if requested by a maintainer or the Principal
|
||||
Architect. Security related changes may override a maintainer's
|
||||
wishes at the Security Officer's discretion.</para>
|
||||
<para>Any disputed change must be backed out pending
|
||||
resolution of the dispute if requested by a maintainer or
|
||||
the Principal Architect. Security related changes may
|
||||
override a maintainer's wishes at the Security Officer's
|
||||
discretion.</para>
|
||||
|
||||
<para>This may be hard to swallow in times of conflict (when each
|
||||
side is convinced that they're in the right, of course) but CVS
|
||||
makes it unnecessary to have an ongoing dispute raging when it's
|
||||
far easier to simply reverse the disputed change, get everyone
|
||||
calmed down again and then try and figure out how best to proceed.
|
||||
If the change turns out to be the best thing after all, it can be
|
||||
easily brought back. If it turns out not to be, then the users
|
||||
didn't have to live with the bogus change in the tree while
|
||||
everyone was busily debating its merits. People very very rarely
|
||||
call for back-outs in the repository since discussion generally
|
||||
exposes bad or controversial changes before the commit even
|
||||
happens, but on such rare occasions the back-out should be done
|
||||
without argument so that we can get immediately on to the topic of
|
||||
figuring out whether it was bogus or not.</para>
|
||||
<para>This may be hard to swallow in times of conflict (when
|
||||
each side is convinced that they're in the right, of
|
||||
course) but CVS makes it unnecessary to have an ongoing
|
||||
dispute raging when it's far easier to simply reverse the
|
||||
disputed change, get everyone calmed down again and then
|
||||
try and figure out how best to proceed. If the change
|
||||
turns out to be the best thing after all, it can be easily
|
||||
brought back. If it turns out not to be, then the users
|
||||
didn't have to live with the bogus change in the tree
|
||||
while everyone was busily debating its merits. People
|
||||
very very rarely call for back-outs in the repository
|
||||
since discussion generally exposes bad or controversial
|
||||
changes before the commit even happens, but on such rare
|
||||
occasions the back-out should be done without argument so
|
||||
that we can get immediately on to the topic of figuring
|
||||
out whether it was bogus or not.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before <literal>-STABLE</literal> unless specifically
|
||||
permitted by the release engineer or unless they're not applicable
|
||||
to <literal>-CURRENT</literal>. Any non-trivial or non-urgent change which is
|
||||
applicable should also be allowed to sit in <literal>-CURRENT</literal> for at least
|
||||
3 days before merging so that it can be given sufficient testing.
|
||||
The release engineer has the same authority over the <literal>-STABLE</literal>
|
||||
branch as outlined in rule #5.</para>
|
||||
<para>Changes go to <literal>-CURRENT</literal> before
|
||||
<literal>-STABLE</literal> unless specifically permitted
|
||||
by the release engineer or unless they're not applicable
|
||||
to <literal>-CURRENT</literal>. Any non-trivial or
|
||||
non-urgent change which is applicable should also be
|
||||
allowed to sit in <literal>-CURRENT</literal> for at least
|
||||
3 days before merging so that it can be given sufficient
|
||||
testing. The release engineer has the same authority over
|
||||
the <literal>-STABLE</literal> branch as outlined in rule
|
||||
#5.</para>
|
||||
|
||||
<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
|
||||
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
|
||||
<literal>-STABLE</literal> branch. The management of <literal>-STABLE</literal> may frequently seem to
|
||||
be overly conservative to the casual observer, but also bear in
|
||||
mind the fact that conservatism is supposed to be the hallmark of
|
||||
<literal>-STABLE</literal> and different rules apply there than in <literal>-CURRENT</literal>. There's
|
||||
also really no point in having <literal>-CURRENT</literal> be a testing ground if
|
||||
changes are merged over to <literal>-STABLE</literal> immediately. Changes need
|
||||
a chance to be tested by the <literal>-CURRENT</literal> developers, so allow some
|
||||
time to elapse before merging unless the <literal>-STABLE</literal> fix is critical,
|
||||
<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 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
|
||||
<literal>-STABLE</literal> branch. The management of
|
||||
<literal>-STABLE</literal> may frequently seem to be
|
||||
overly conservative to the casual observer, but also bear
|
||||
in mind the fact that conservatism is supposed to be the
|
||||
hallmark of <literal>-STABLE</literal> and different rules
|
||||
apply there than in <literal>-CURRENT</literal>. There's
|
||||
also really no point in having <literal>-CURRENT</literal>
|
||||
be a testing ground if changes are merged over to
|
||||
<literal>-STABLE</literal> immediately. Changes need a
|
||||
chance to be tested by the <literal>-CURRENT</literal>
|
||||
developers, so allow some time to elapse before merging
|
||||
unless the <literal>-STABLE</literal> fix is critical,
|
||||
time sensitive or so obvious as to make further testing
|
||||
unnecessary (spelling fixes to manpages, obvious bug/typo fixes,
|
||||
etc.) In other words, apply common sense.</para>
|
||||
unnecessary (spelling fixes to manpages, obvious bug/typo
|
||||
fixes, etc.) In other words, apply common sense.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Don't fight in public with other committers; it looks bad. If
|
||||
you must <quote>strongly disagree</quote> about something, do so
|
||||
only in private.</para>
|
||||
<para>Don't fight in public with other committers; it looks
|
||||
bad. If you must <quote>strongly disagree</quote> about
|
||||
something, do so only in private.</para>
|
||||
|
||||
<para>This project has a public image to uphold and that image is
|
||||
very important to all of us, especially if we are to continue to
|
||||
attract new members. There will be occasions when, despite
|
||||
everyone's very best attempts at self-control, tempers are lost
|
||||
and angry words are exchanged, and the best we can do is try and
|
||||
minimize the effects of this until everyone has cooled back down.
|
||||
That means that you should not air your angry words in public and
|
||||
you should not forward private correspondence to public mailing
|
||||
lists or aliases. What people say one-to-one is often much less
|
||||
sugar-coated than what they would say in public, and such
|
||||
communications therefore have no place there - they only serve to
|
||||
inflame an already bad situation. If the person sending you a
|
||||
flame-o-gram at least had the grace to send it privately, then
|
||||
have the grace to keep it private yourself. If you feel you are
|
||||
being unfairly treated by another developer, and it is causing you
|
||||
anguish, bring the matter up with core rather than taking it
|
||||
public. We will do our best to play peace makers and get things
|
||||
back to sanity. In cases where the dispute involves a change to
|
||||
the codebase and the participants do not appear to be reaching an
|
||||
amicable agreement, core may appoint a mutually-agreeable 3rd
|
||||
party to resolve the dispute. All parties involved must then
|
||||
<para>This project has a public image to uphold and that
|
||||
image is very important to all of us, especially if we are
|
||||
to continue to attract new members. There will be
|
||||
occasions when, despite everyone's very best attempts at
|
||||
self-control, tempers are lost and angry words are
|
||||
exchanged, and the best we can do is try and minimize the
|
||||
effects of this until everyone has cooled back down. That
|
||||
means that you should not air your angry words in public
|
||||
and you should not forward private correspondence to
|
||||
public mailing lists or aliases. What people say
|
||||
one-to-one is often much less sugar-coated than what they
|
||||
would say in public, and such communications therefore
|
||||
have no place there - they only serve to inflame an
|
||||
already bad situation. If the person sending you a
|
||||
flame-o-gram at least had the grace to send it privately,
|
||||
then have the grace to keep it private yourself. If you
|
||||
feel you are being unfairly treated by another developer,
|
||||
and it is causing you anguish, bring the matter up with
|
||||
core rather than taking it public. We will do our best to
|
||||
play peace makers and get things back to sanity. In cases
|
||||
where the dispute involves a change to the codebase and
|
||||
the participants do not appear to be reaching an amicable
|
||||
agreement, core may appoint a mutually-agreeable 3rd party
|
||||
to resolve the dispute. All parties involved must then
|
||||
agree to be bound by the decision reached by this 3rd
|
||||
party.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Respect all code freezes and read the <literal>committers</literal> mailing list
|
||||
on a timely basis so you know when they are.</para>
|
||||
<para>Respect all code freezes and read the
|
||||
<literal>committers</literal> mailing list on a timely
|
||||
basis so you know when they are.</para>
|
||||
|
||||
<para>Committing changes during a code freeze is a really big
|
||||
mistake and committers are expected to keep up-to-date on what's
|
||||
going on before jumping in after a long absence 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 FreeBSD Happy Reeducation Camp we run in
|
||||
Greenland.</para>
|
||||
<para>Committing changes during a code freeze is a really
|
||||
big mistake and committers are expected to keep up-to-date
|
||||
on what's going on before jumping in after a long absence
|
||||
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
|
||||
FreeBSD Happy Reeducation Camp we run in Greenland.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>When in doubt on any procedure, ask first!</para>
|
||||
|
||||
<para>Many mistakes are made because someone is in a hurry and
|
||||
just assumes they know the right way of doing something. If
|
||||
you have not done it before, chances are good that you do not
|
||||
actually know the way we do things and really need to ask first or
|
||||
you are going to completely embarrass yourself in public. There's
|
||||
no shame in asking <quote>how in the heck do I do this?</quote>
|
||||
We already know you are an intelligent person; otherwise, you would not be a
|
||||
committer.</para>
|
||||
<para>Many mistakes are made because someone is in a hurry
|
||||
and just assumes they know the right way of doing
|
||||
something. If you have not done it before, chances are
|
||||
good that you do not actually know the way we do things
|
||||
and really need to ask first or you are going to
|
||||
completely embarrass yourself in public. There's no shame
|
||||
in asking <quote>how in the heck do I do this?</quote> We
|
||||
already know you are an intelligent person; otherwise, you
|
||||
would not be a committer.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Test your changes before committing them.</para>
|
||||
|
||||
<para>This may sound obvious, but if it really were so obvious then
|
||||
we probably wouldn't see so many cases of people clearly not doing
|
||||
this. If your changes are to the kernel, make sure you can still
|
||||
compile both GENERIC and LINT. If your changes are anywhere else,
|
||||
make sure you can still make world. If your changes are to a
|
||||
branch, make sure your testing occurs with a machine which is
|
||||
running that code. If you have a change which also may break
|
||||
another architecture, be sure and test on all supported
|
||||
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
|
||||
account on <hostid role="fqdn">beast.FreeBSD.org</hostid> will let
|
||||
you compile and test alpha binaries/kernels/etc. As other
|
||||
architectures are added to the FreeBSD supported platforms list,
|
||||
the appropriate shared testing resources will be made
|
||||
available.</para>
|
||||
<para>This may sound obvious, but if it really were so
|
||||
obvious then we probably wouldn't see so many cases of
|
||||
people clearly not doing this. If your changes are to the
|
||||
kernel, make sure you can still compile both GENERIC and
|
||||
LINT. If your changes are anywhere else, make sure you
|
||||
can still make world. If your changes are to a branch,
|
||||
make sure your testing occurs with a machine which is
|
||||
running that code. If you have a change which also may
|
||||
break another architecture, be sure and test on all
|
||||
supported 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 account on <hostid
|
||||
role="fqdn">beast.FreeBSD.org</hostid> will let you
|
||||
compile and test alpha binaries/kernels/etc. As other
|
||||
architectures are added to the FreeBSD supported platforms
|
||||
list, the appropriate shared testing resources will be
|
||||
made available.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</sect2>
|
||||
|
|
@ -772,26 +822,27 @@
|
|||
<sect2>
|
||||
<title>Other Suggestions</title>
|
||||
|
||||
<para>When committing documentation changes, use a
|
||||
spell checker before committing. :) For all SGML docs, you should
|
||||
also verify that your formatting directives are correct by running
|
||||
<para>When committing documentation changes, use a spell checker
|
||||
before committing. :) For all SGML docs, you should also
|
||||
verify that your formatting directives are correct by running
|
||||
<command>make lint</command>.</para>
|
||||
|
||||
<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
|
||||
are correct and that the man page has all of the appropriate
|
||||
<makevar>MLINK</makevar>s installed.</para>
|
||||
<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 are correct and that the man
|
||||
page has all of the appropriate <makevar>MLINK</makevar>s
|
||||
installed.</para>
|
||||
|
||||
<para>Do not mix style fixes with new functionality. A style
|
||||
fix is any change which does not modify the functionality of
|
||||
the code. Mixing the changes ofucsates the functionality
|
||||
change when using <command>cvs diff</command>, which can hide
|
||||
any new bugs. Do not
|
||||
include whitespace changes with content changes in commits to
|
||||
<filename>doc/</filename> or <filename>www/</filename>. The extra clutter in the diffs
|
||||
makes the translators' job much more difficult. Instead, make any
|
||||
style or whitespace changes in seperate commits that are clearly
|
||||
labeled as such in the commit message.</para>
|
||||
any new bugs. Do not include whitespace changes with content
|
||||
changes in commits to <filename>doc/</filename> or
|
||||
<filename>www/</filename>. The extra clutter in the diffs
|
||||
makes the translators' job much more difficult. Instead, make
|
||||
any style or whitespace changes in seperate commits that are
|
||||
clearly labeled as such in the commit message.</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -815,9 +866,10 @@
|
|||
<command>easy-import</command> script on
|
||||
<hostid>freefall</hostid>. It will ask you some
|
||||
questions and import the port in the directory you
|
||||
specify. It will also add an entry to the <filename>CVSROOT/modules</filename>
|
||||
file. It was written by &a.joerg; so please send mail
|
||||
to him if you have questions about
|
||||
specify. It will also add an entry to the
|
||||
<filename>CVSROOT/modules</filename> file. It was
|
||||
written by &a.joerg; so please send mail to him if you
|
||||
have questions about
|
||||
<command>easy-import</command>.</para>
|
||||
|
||||
<para>One thing it will not do for you is add the port to
|
||||
|
|
@ -857,8 +909,8 @@
|
|||
|
||||
<para>If the port came from a submitter who has not
|
||||
contributed to the project before, add that person's
|
||||
name to the Handbook's
|
||||
<citetitle pubwork="section">Additional Contributors</citetitle>
|
||||
name to the Handbook's <citetitle
|
||||
pubwork="section">Additional Contributors</citetitle>
|
||||
section.</para>
|
||||
|
||||
<para>Close the PR if the port came in as a PR. To close
|
||||
|
|
@ -1024,17 +1076,19 @@
|
|||
<answer>
|
||||
<para>The ports manager will send out warning messages to
|
||||
the <email>freebsd-ports@FreeBSD.org</email> and
|
||||
<email>cvs-committers@FreeBSD.org</email> mailing lists announcing
|
||||
the start of the impending release, usually two or three
|
||||
weeks in advance. The exact starting time will not be
|
||||
determined until a few days before the actual release.
|
||||
This is because the ports freeze has to be synchronized
|
||||
with the release, and it is usually not known until then
|
||||
when exactly the release will be rolled.</para>
|
||||
<email>cvs-committers@FreeBSD.org</email> mailing lists
|
||||
announcing the start of the impending release, usually
|
||||
two or three weeks in advance. The exact starting time
|
||||
will not be determined until a few days before the
|
||||
actual release. This is because the ports freeze has to
|
||||
be synchronized with the release, and it is usually not
|
||||
known until then when exactly the release will be
|
||||
rolled.</para>
|
||||
|
||||
<para>When the freeze starts, there will be another
|
||||
announcement to the <email>cvs-committers@FreeBSD.org</email>
|
||||
list, of course.</para>
|
||||
announcement to the
|
||||
<email>cvs-committers@FreeBSD.org</email> list, of
|
||||
course.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
|
|
@ -1046,8 +1100,8 @@
|
|||
<answer>
|
||||
<para>A few hours after the release, the ports manager
|
||||
will send out a mail to the
|
||||
<email>freebsd-ports@FreeBSD.org</email> and
|
||||
<email>cvs-committers@FreeBSD.org</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
|
||||
release being cut does not automatically end the freeze.
|
||||
We have to make sure there will not be any last minute
|
||||
|
|
@ -1147,14 +1201,16 @@
|
|||
</question>
|
||||
|
||||
<answer>
|
||||
<para>The RCS file format is quite braindead and certain operations
|
||||
to achieve things for CVS are hideously expensive for the
|
||||
repository. Making changes to files on a vendor branch, thereby
|
||||
pulling the file off that branch, is one example of this.</para>
|
||||
<para>The RCS file format is quite braindead and certain
|
||||
operations to achieve things for CVS are hideously
|
||||
expensive for the repository. Making changes to files on
|
||||
a vendor branch, thereby pulling the file off that branch,
|
||||
is one example of this.</para>
|
||||
|
||||
<para>Suppose you have a file which was first imported on a vendor
|
||||
branch, and was then re-imported three times (still on the vendor
|
||||
branch) as the vendor makes updates to the file.</para>
|
||||
<para>Suppose you have a file which was first imported on a
|
||||
vendor branch, and was then re-imported three times (still
|
||||
on the vendor branch) as the vendor makes updates to the
|
||||
file.</para>
|
||||
|
||||
<segmentedlist>
|
||||
<seglistitem>
|
||||
|
|
@ -1178,21 +1234,25 @@
|
|||
</seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<para>Now suppose that one of the FreeBSD committers makes a one
|
||||
line change to this file, causing it to go to version 1.2. This
|
||||
causes it to leave the branch, resulting in 4,001 lines being added
|
||||
to the file's history, and 2,001 lines being deleted.</para>
|
||||
<para>Now suppose that one of the FreeBSD committers makes a
|
||||
one line change to this file, causing it to go to version
|
||||
1.2. This causes it to leave the branch, resulting in
|
||||
4,001 lines being added to the file's history, and 2,001
|
||||
lines being deleted.</para>
|
||||
|
||||
<para>This is because the 1.2 delta is stored relative to 1.1.1.1,
|
||||
<emphasis>not</emphasis> 1.1.1.4, and so the entire vendor history
|
||||
is duplicated in the 1.2 delta. Now, repeat this for 2000 files
|
||||
in a large directory, it adds up a lot.</para>
|
||||
<para>This is because the 1.2 delta is stored relative to
|
||||
1.1.1.1, <emphasis>not</emphasis> 1.1.1.4, and so the
|
||||
entire vendor history is duplicated in the 1.2 delta.
|
||||
Now, repeat this for 2000 files in a large directory, it
|
||||
adds up a lot.</para>
|
||||
|
||||
<para><emphasis>This</emphasis> is why we have such <quote>hands
|
||||
off</quote> policies for <filename>src/contrib</filename> and other things that track
|
||||
the vendor releases. This is why <quote>typo fixes</quote> in man
|
||||
pages and spelling <quote>corrections</quote> are so strongly
|
||||
discouraged for vendor code.</para>
|
||||
<para><emphasis>This</emphasis> is why we have such
|
||||
<quote>hands off</quote> policies for
|
||||
<filename>src/contrib</filename> and other things that
|
||||
track the vendor releases. This is why <quote>typo
|
||||
fixes</quote> in man pages and spelling
|
||||
<quote>corrections</quote> are so strongly discouraged for
|
||||
vendor code.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
</qandaset>
|
||||
|
|
|
|||
Loading…
Reference in a new issue