Source string Read only

(itstool) path: sect3/para
Context English State
would generate a set of unified diffs for the given source file or directory hierarchy.
See <citerefentry><refentrytitle>diff</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more information.
Once you have a set of diffs (which you may test with the <citerefentry><refentrytitle>patch</refentrytitle><manvolnum>1</manvolnum></citerefentry> command), you should submit them for inclusion with FreeBSD as a bug report. <emphasis>Do not</emphasis> just send the diffs to the <link xlink:href="">FreeBSD technical discussions mailing list</link> or they will get lost! We greatly appreciate your submission (this is a volunteer project!); because we are busy, we may not be able to address it immediately, but it will remain in the PR database until we do. Indicate your submission by including <literal>[PATCH]</literal> in the synopsis of the report.
If you feel it appropriate (e.g. you have added, deleted, or renamed files), bundle your changes into a <command>tar</command> file. Archives created with <citerefentry><refentrytitle>shar</refentrytitle><manvolnum>1</manvolnum></citerefentry> are also welcome.
If your change is of a potentially sensitive nature, such as if you are unsure of copyright issues governing its further distribution then you should send it to Core Team <email></email> directly rather than submitting as a bug report. The Core Team <email></email> reaches a much smaller group of people who do much of the day-to-day work on FreeBSD. Note that this group is also <emphasis>very busy</emphasis> and so you should only send mail to them where it is truly necessary.
Please refer to <citerefentry><refentrytitle>intro</refentrytitle><manvolnum>9</manvolnum></citerefentry> and <citerefentry><refentrytitle>style</refentrytitle><manvolnum>9</manvolnum></citerefentry> for some information on coding style. We would appreciate it if you were at least aware of this information before submitting code.
New Code or Major Value-Added Packages
In the case of a significant contribution of a large body work, or the addition of an important new feature to FreeBSD, it becomes almost always necessary to either send changes as tar files or upload them to a web or FTP site for other people to access. If you do not have access to a web or FTP site, ask on an appropriate FreeBSD mailing list for someone to host the changes for you.
When working with large amounts of code, the touchy subject of copyrights also invariably comes up. FreeBSD prefers free software licenses such as BSD or ISC. Copyleft licenses such as GPLv2 are sometimes permitted. The complete listing can be found on the <link xlink:href="@@URL_RELPREFIX@@/internal/software-license.html">core team licensing policy</link> page.
Money or Hardware
We are always very happy to accept donations to further the cause of the FreeBSD Project and, in a volunteer effort like ours, a little can go a long way! Donations of hardware are also very important to expanding our list of supported peripherals since we generally lack the funds to buy such items ourselves.
Donating Funds
The <link xlink:href="">FreeBSD Foundation</link> is a non-profit, tax-exempt foundation established to further the goals of the FreeBSD Project. As a 501(c)3 entity, the Foundation is generally exempt from US federal income tax as well as Colorado State income tax. Donations to a tax-exempt entity are often deductible from taxable federal income.

The FreeBSD Foundation
<street>P.O. Box 20247</street>,
<state>CO</state> <postcode>80308</postcode>
Donations may be sent in check form to: <_:address-1/>
The FreeBSD Foundation is also able to accept <link xlink:href=""> online donations</link> through various payment options.
More information about the FreeBSD Foundation can be found in <link xlink:href="">The FreeBSD Foundation -- an Introduction</link>. To contact the Foundation by email, write to <email></email>.
Donating Hardware
The FreeBSD Project happily accepts donations of hardware that it can find good use for. If you are interested in donating hardware, please contact the <link xlink:href="@@URL_RELPREFIX@@/donations/">Donations Liaison Office</link>.
Contributing to ports
Adopting an unmaintained port
Choosing an unmaintained port
Taking over maintainership of ports that are unmaintained is a great way to get involved. Unmaintained ports are only updated and fixed when somebody volunteers to work on them. There are a large number of unmaintained ports. It is a good idea to start with adopting a port that you use regularly.
Unmaintained ports have their <varname>MAINTAINER</varname> set to <literal></literal>. A list of unmaintained ports and their current errors and problem reports can be seen at the <link xlink:href="">FreeBSD Ports Monitoring System</link>.
Some ports affect a large number of others due to dependencies and slave port relationships. Generally, we want people to have some experience before they maintain such ports.
You can find out whether or not a port has dependencies or slave ports by looking at a master index of ports called <filename>INDEX</filename>. (The name of the file varies by release of FreeBSD; for instance, <filename>INDEX-8</filename>.) Some ports have conditional dependencies that are not included in a default <filename>INDEX</filename> build. We expect you to be able to recognize such ports by looking through other ports' <filename>Makefile</filename>s.
How to adopt the port
First make sure you understand your <link linkend="maintain-port">responsibilities as a maintainer</link>. Also read the <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/books/porters-handbook">Porter's Handbook</link>. <emphasis>Please do not commit yourself to more than you feel you can comfortably handle.</emphasis>
You may request maintainership of any unmaintained port as soon as you wish. Simply set <varname>MAINTAINER</varname> to your own email address and send a PR (Problem Report) with the change. If the port has build errors or needs updating, you may wish to include any other changes in the same PR. This will help because many committers are less willing to assign maintainership to someone who does not have a known track record with FreeBSD. Submitting PRs that fix build errors or update ports are the best ways to establish one.
File your PR with category <literal>ports</literal> and class <literal>change-request</literal>. A committer will examine your PR, commit the changes, and finally close the PR. Sometimes this process can take a little while (committers are volunteers, too :).


User avatar None

New source string

FreeBSD Doc / articles_contributingEnglish

New source string 5 months ago
Browse all component changes


English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Source string location
String age
5 months ago
Source string age
5 months ago
Translation file
articles/contributing.pot, string 85