Source string Read only

(itstool) path: listitem/para
283/2830
Context English State
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 is 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.
This may sound obvious, but if it really were so obvious then we probably would not 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. Please refer to the <link xlink:href="https://www.FreeBSD.org/internal/">FreeBSD Internal Page</link> for a list of available resources. As other architectures are added to the FreeBSD supported platforms list, the appropriate shared testing resources will be made available.
Contributed software is anything under the <filename>src/contrib</filename>, <filename>src/crypto</filename>, or <filename>src/sys/contrib</filename> trees.
The trees mentioned above are for contributed software usually imported onto a vendor branch. Committing something there may cause unnecessary headaches when importing newer versions of the software. As a general consider sending patches upstream to the vendor. Patches may be committed to FreeBSD first with permission of the maintainer.
Reasons for modifying upstream software range from wanting strict control over a tightly coupled dependency to lack of portability in the canonical repository's distribution of their code. Regardless of the reason, effort to minimize the maintenance burden of fork is helpful to fellow maintainers. Avoid committing trivial or cosmetic changes to files since it makes every merge thereafter more difficult: such patches need to be manually re-verified every import.
If a particular piece of software lacks a maintainer, you are encouraged to take up ownership. If you are unsure of the current maintainership email <link xlink:href="http://lists.FreeBSD.org/mailman/listinfo/freebsd-arch">FreeBSD architecture and design mailing list</link> and ask.
Policy on Multiple Architectures
FreeBSD has added several new architecture ports during recent release cycles and is truly no longer an <trademark>i386</trademark> centric operating system. In an effort to make it easier to keep FreeBSD portable across the platforms we support, core has developed this mandate:
Our 32-bit reference platform is i386, and our 64-bit reference platform is amd64. Major design work (including major API and ABI changes) must prove itself on at least one 32-bit and at least one 64-bit platform, preferably the primary reference platforms, before it may be committed to the source tree.
The i386 and amd64 platforms were chosen due to being more readily available to developers and as representatives of more diverse processor and system designs - big versus little endian, register file versus register stack, different DMA and cache implementations, hardware page tables versus software TLB management etc.
We will continue to re-evaluate this policy as cost and availability of the 64-bit platforms change.

Loading…

None

New source string

FreeBSD Doc / articles_committers-guideEnglish

New source string 2 weeks ago
Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: listitem/para
Labels
No labels currently set.
Flags
read-only
Source string location
article.translate.xml:3726
Source string age
2 weeks ago
Translation file
, string 691