Source string Read only

(itstool) path: sect2/title
17/170
Context English State
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. The best thing that can be done in such cases is to minimize the effects of this until everyone has cooled back down. Do not air angry words in public and do not forward private correspondence or other private communications to public mailing lists, mail aliases, instant messaging channels or social media sites. 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 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. Core will do its 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 third party to resolve the dispute. All parties involved must then agree to be bound by the decision reached by this third party.
Respect all code freezes and read the <literal>committers</literal> and <literal>developers</literal> mailing list on a timely basis so you know when a code freeze is in effect.
Committing unapproved changes during a code freeze is a really big mistake and committers are expected to keep up-to-date on what is 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.
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.
Developers should also be aware of our Tier Policy for the long term support of hardware architectures. The rules here are intended to provide guidance during the development process, and are distinct from the requirements for features and architectures listed in that section. The Tier rules for feature support on architectures at release-time are more strict than the rules for changes during the development process.
Other Suggestions
When committing documentation changes, use a spell checker before committing. For all XML docs, verify that the formatting directives are correct by running <command>make lint</command> and <package>textproc/igor</package>.
For manual pages, run <package>sysutils/manck</package> and <package>textproc/igor</package> over the manual page to verify all of the cross references and file references are correct and that the man page has all of the appropriate <varname>MLINK</varname>s installed.
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 obfuscates the functionality change when asking for differences between revisions, which can hide any new bugs. Do not include whitespace changes with content changes in commits to <filename>doc/</filename> . The extra clutter in the diffs makes the translators' job much more difficult. Instead, make any style or whitespace changes in separate commits that are clearly labeled as such in the commit message.
Deprecating Features
When it is necessary to remove functionality from software in the base system, follow these guidelines whenever possible:
Mention is made in the manual page and possibly the release notes that the option, utility, or interface is deprecated. Use of the deprecated feature generates a warning.
The option, utility, or interface is preserved until the next major (point zero) release.
The option, utility, or interface is removed and no longer documented. It is now obsolete. It is also generally a good idea to note its removal in the release notes.
Privacy and Confidentiality
Most FreeBSD business is done in public.
FreeBSD is an <emphasis>open</emphasis> project. Which means that not only can anyone use the source code, but that most of the development process is open to public scrutiny.
Certain sensitive matters must remain private or held under embargo.
There unfortunately cannot be complete transparency. As a FreeBSD developer you will have a certain degree of privileged access to information. Consequently you are expected to respect certain requirements for confidentiality. Sometimes the need for confidentiality comes from external collaborators or has a specific time limit. Mostly though, it is a matter of not releasing private communications.
The Security Officer has sole control over the release of security advisories.
Where there are security problems that affect many different operating systems, FreeBSD frequently depends on early access to be able to prepare advisories for coordinated release. Unless FreeBSD developers can be trusted to maintain security, such early access will not be made available. The Security Officer is responsible for controlling pre-release access to information about vulnerabilities, and for timing the release of all advisories. He may request help under condition of confidentiality from any developer with relevant knowledge to prepare security fixes.

Loading…

No matching activity found.

Browse all component changes

Things to check

Long untranslated

The string has not been translated for a long time

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/title
Flags
read-only
Source string location
article.translate.xml:3771
String age
a year ago
Source string age
a year ago
Translation file
articles/committers-guide.pot, string 697