The translation is temporarily closed for contributions due to maintenance, please come back later.
Context English State
_ translator-credits
FreeBSD is a registered trademark of the FreeBSD Foundation.
<prompt>%</prompt> <userinput>gpg --full-gen-key</userinput>
gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Warning: using insecure memory!
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? <userinput>1</userinput>
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) <userinput>2048</userinput> <co xml:id="co-pgp-bits"/>
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
&lt;n&gt; = key expires in n days
&lt;n&gt;w = key expires in n weeks
&lt;n&gt;m = key expires in n months
&lt;n&gt;y = key expires in n years
Key is valid for? (0) <userinput>3y</userinput> <co xml:id="co-pgp-expire"/>
Key expires at Wed Nov 4 17:20:20 2015 MST
Is this correct? (y/N) <userinput>y</userinput>

GnuPG needs to construct a user ID to identify your key.

Real name: <userinput><replaceable>Chucky Daemon</replaceable></userinput> <co xml:id="co-pgp-realname"/>
Email address: <userinput><replaceable>notreal@example.com</replaceable></userinput>
Comment:
You selected this USER-ID:
"<replaceable>Chucky Daemon &lt;notreal@example.com&gt;</replaceable>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? <userinput>o</userinput>
You need a Passphrase to protect your secret key.
The FreeBSD <literal>doc/www</literal> repository switched from <acronym>CVS</acronym> to Subversion on May 19th, 2012. The first real <acronym>SVN</acronym> commit is <emphasis>r38821</emphasis>.
Files are added to a <acronym>SVN</acronym> repository with <command>svn add</command>. To add a file named <emphasis>foo</emphasis>, edit it, then:
Subversion does not require deleting the file before using <command>svn rm</command>, and indeed complains if that happens.
Now, import the sources into the <filename>dist</filename> directory. Once the files are in place, <command>svn add</command> the new ones, then <command>svn commit</command> and tag the imported version. To save time and bandwidth, direct remote committing and tagging is possible:
All <filename>src</filename> commits go to FreeBSD-CURRENT first before being merged to FreeBSD-STABLE. The FreeBSD-STABLE branch must maintain <acronym>ABI</acronym> and <acronym>API</acronym> compatibility with earlier versions of that branch. Do not merge changes that break this compatibility.
When the mentor decides that a mentee has learned the ropes and is ready to commit on their own, the mentor announces it with a commit to <filename>conf/mentors</filename>. This file is in the <filename>svnadmin</filename> branch of each repository:
Glen Barber <email>gjb@FreeBSD.org</email>, Konstantin Belousov <email>kib@FreeBSD.org</email>, Bryan Drewery <email>bdrewery@FreeBSD.org</email>, Marc Fonvieille <email>blackend@FreeBSD.org</email>, Xin Li <email>delphij@FreeBSD.org</email>, Colin Percival <email>cperciva@FreeBSD.org</email> Hiroki Sato <email>hrs@FreeBSD.org</email>, Gleb Smirnoff <email>glebius@FreeBSD.org</email>
This is another <quote>do not argue about it</quote> issue since it is 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 FreeBSD-STABLE branch. The management of FreeBSD-STABLE 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 FreeBSD-STABLE and different rules apply there than in FreeBSD-CURRENT. There is also really no point in having FreeBSD-CURRENT be a testing ground if changes are merged over to FreeBSD-STABLE immediately. Changes need a chance to be tested by the FreeBSD-CURRENT developers, so allow some time to elapse before merging unless the FreeBSD-STABLE fix is critical, time sensitive or so obvious as to make further testing unnecessary (spelling fixes to manual pages, obvious bug/typo fixes, etc.) In other words, apply common sense.