Differential D16089 Diff 45898 en_US.ISO8859-1/articles/committers-guide/article.xml

Changeset View

Standalone View

en_US.ISO8859-1/articles/committers-guide/article.xml

Show First 20 Lines • Show All 3,179 Lines • ▼ Show 20 Lines	*/</programlisting>
<para>When in doubt on any procedure, ask first!</para>		<para>When in doubt on any procedure, ask first!</para>
</listitem>		</listitem>

<listitem>		<listitem>
<para>Test your changes before committing them.</para>		<para>Test your changes before committing them.</para>
</listitem>		</listitem>

<listitem>		<listitem>
<para>Do not commit to anything under the		<para>Do not commit to contributed software without
<filename>src/contrib</filename>,
<filename>src/crypto</filename>, or
<filename>src/sys/contrib</filename> trees without
<emphasis>explicit</emphasis> approval from the respective		<emphasis>explicit</emphasis> approval from the respective
maintainers.</para>		maintainers.</para>
</listitem>		</listitem>
</orderedlist>		</orderedlist>

<para>As noted, breaking some of these rules can be grounds for		<para>As noted, breaking some of these rules can be grounds for
suspension or, upon repeated offense, permanent removal of		suspension or, upon repeated offense, permanent removal of
commit privileges. Individual members of core have the power to		commit privileges. Individual members of core have the power to
▲ Show 20 Lines • Show All 290 Lines • ▼ Show 20 Lines	<para>This may sound obvious, but if it really were so
<link xlink:href="https://www.FreeBSD.org/internal/">&os;		<link xlink:href="https://www.FreeBSD.org/internal/">&os;
Internal Page</link> for a list of available resources.		Internal Page</link> for a list of available resources.
As other architectures are added to the &os; supported		As other architectures are added to the &os; supported
platforms list, the appropriate shared testing resources		platforms list, the appropriate shared testing resources
will be made available.</para>		will be made available.</para>
</listitem>		</listitem>

<listitem>		<listitem>
<para>Do not commit to anything under the		<para>Do not commit to contributed software without
<filename>src/contrib</filename>,
<filename>src/crypto</filename>, and
<filename>src/sys/contrib</filename> trees without
<emphasis>explicit</emphasis> approval from the respective		<emphasis>explicit</emphasis> approval from the respective
maintainers.</para>		maintainers.</para>

		<para>Contributed software is anything under the
		<filename>src/contrib</filename>,
		<filename>src/crypto</filename>, or
		<filename>src/sys/contrib</filename> trees.</para>

<para>The trees mentioned above are for contributed software		<para>The trees mentioned above are for contributed software
usually imported onto a vendor branch. Committing		usually imported onto a vendor branch. Committing
something there, even if it does not take the file off the		something there may cause unnecessary headaches
vendor branch, may cause unnecessary headaches for those		when importing newer versions of the software. As a
responsible for maintaining that particular piece of		general consider sending patches upstream to the vendor.
		emasteUnsubmitted Done Inline Actions I might write "As a general rule" instead of "Strongly consider" emaste: I might write "As a general rule" instead of "Strongly consider"
		rpokalaUnsubmitted Not Done Inline Actions "general consider" => "general rule, consider" rpokala: "general consider" => "general rule, consider"
software. Thus, unless you have		Patches may be committed to FreeBSD first with permission
<emphasis>explicit</emphasis> approval from the maintainer		of the maintainer.</para>
		jhbUnsubmitted Done Inline Actions s/for when/when/ jhb: s/for when/when/
		emasteUnsubmitted Done Inline Actions comma not needed emaste: comma not needed
(or you are the maintainer), do <emphasis>not</emphasis>
commit there!</para>

<!-- FIXME: this paragraph should be rewritten -->		<para>Reasons for modifying upstream software range from
<para>Please note that this does not mean you should not try		wanting strict control over a tightly coupled dependency
to improve the software in question; you are still more		to lack of portability in the canonical
than welcome to do so. Ideally, submit your		repository's distribution of their code. Regardless of the
		seancUnsubmitted Done Inline Actions Can we strengthen the language here slightly? Something like: `contrib/` software is home to various forks of upstream software that the FreeBSD Project has agreed to maintain locally. The reasons for maintaining a fork ranges from wanting strict control over a tightly coupled dependency to lack of portability or trust in the canonical repository's distribution of their code. Regardless of the reason(s), effort to minimize the maintenance burden of fork is helpful to fellow maintainers. seanc: Can we strengthen the language here slightly? Something like: > `contrib/` software is home…
patches to the vendor. If your changes are		reason, effort to minimize the maintenance burden of
&os;-specific, talk to the maintainer; they may be		fork is helpful to fellow maintainers. Avoid committing
willing to apply them locally. But whatever you do, do		trivial or cosmetic changes to files
<emphasis>not</emphasis> commit there by yourself!</para>		since it makes every merge thereafter more
		difficult: such patches need to be manually re-verified
		every import.</para>
		jhbUnsubmitted Done Inline Actions s/comitting/committing/ jhb: s/comitting/committing/
		rpokalaUnsubmitted Not Done Inline Actions "every import." => "as part of every import." or "after every import." rpokala: "every import." => "as part of every import." or "after every import."

<para>Contact the &a.core; if you wish to take up		<para>If a particular piece of software lacks a maintainer,
maintainership of an unmaintained part of the tree.</para>		you're encouraged to take up owership. If you're unsure
		seancUnsubmitted Done Inline Actions you're encourage to take up ownership (or reevaluate whether or not we need to maintain our own independent fork and can possibly get by with a ports-managed) distribution of the contributed software. If we don't have a maintainer for something it's also worth providing a small hint that we can also reexamine whether or not we want the code in `contrib/` at all. This advice isn't limited to `contrib/` but bears repetition because our forks are always inherently out of date with the canonical upstream repository. seanc: > you're encourage to take up ownership (or reevaluate whether or not we need to maintain our…
		eadlerAuthorUnsubmitted Done Inline Actions I'd rather not add this. It leads to the "What should be in base" debate. Unless and until we have a meaningful standard for that, this will just result in bikesheds. eadler: I'd rather not add this. It leads to the "What should be in base" debate. Unless and until we…
		of the current maintainership email &a.arch; and
		rpokalaUnsubmitted Not Done Inline Actions "maintainership email" => "maintainership, email" rpokala: "maintainership email" => "maintainership, email"
		ask.</para>
</listitem>		</listitem>
</orderedlist>		</orderedlist>
</sect2>		</sect2>

<sect2>		<sect2>
<title>Policy on Multiple Architectures</title>		<title>Policy on Multiple Architectures</title>

<para>&os; has added several new architecture ports during		<para>&os; has added several new architecture ports during
▲ Show 20 Lines • Show All 1,549 Lines • ▼ Show 20 Lines	</listitem>
</itemizedlist>		</itemizedlist>
</sect2>		</sect2>
</sect1>		</sect1>

<sect1 xml:id="misc">		<sect1 xml:id="misc">
<title>Miscellaneous Questions</title>		<title>Miscellaneous Questions</title>

<qandaset>		<qandaset>
<qandaentry>
<question>
<para>Why are trivial or cosmetic changes to files on a
vendor branch a bad idea?</para>
</question>

<answer>
<itemizedlist>
<listitem>
<para>From now on, every new vendor release of that file
will need to have patches merged in by hand.</para>
</listitem>

<listitem>
<para>From now on, every new vendor release of that file
will need to have patches
<emphasis>verified</emphasis> by hand.</para>
</listitem>
</itemizedlist>
</answer>
</qandaentry>

<qandaentry>		<qandaentry>
<question>		<question>
<para>How do I add a new file to a branch?</para>		<para>How do I add a new file to a branch?</para>
</question>		</question>

<answer>		<answer>
<para>To add a file onto a branch, simply checkout or update		<para>To add a file onto a branch, simply checkout or update
to the branch you want to add to and then add the file		to the branch you want to add to and then add the file
▲ Show 20 Lines • Show All 108 Lines • Show Last 20 Lines