When working directly on your own code or on code which is
already well established as your responsibility, then there is
probably little need to check with other committers before
jumping in with a commit. Working on a bug in an area of the
system which is clearly orphaned (and there are a few such
areas, to our shame), the same applies. When modifying
parts of the system which are maintained, formally, or
informally, consider asking for review just as a developer
would have before becoming a
committer. For ports, contact the listed
MAINTAINER
in the
Makefile
.
To determine if an area of the tree is maintained, check the
MAINTAINERS file at the root of the tree. If nobody is listed,
scan the revision history to see who has committed
changes in the past. An example script that lists each person
who has committed to a given file along with the number of
commits each person has made can be found at on
freefall
at
~eadler/bin/whodid
. If queries go
unanswered or the committer otherwise indicates a lack of
interest in the area affected, go ahead and commit it.
Avoid sending private emails to maintainers. Other people might be interested in the conversation, not just the final output.
If there is any doubt about a commit for any reason at all, have it reviewed before committing. Better to have it flamed then and there rather than when it is part of the repository. If a commit does results in controversy erupting, it may be advisable to consider backing the change out again until the matter is settled. Remember, with a version control system we can always change it back.
Do not impugn the intentions of others. If they see a different solution to a problem, or even a different problem, it is probably not because they are stupid, because they have questionable parentage, or because they are trying to destroy hard work, personal image, or FreeBSD, but basically because they have a different outlook on the world. Different is good.
Disagree honestly. Argue your position from its merits, be honest about any shortcomings it may have, and be open to seeing their solution, or even their vision of the problem, with an open mind.
Accept correction. We are all fallible. When you have made a mistake, apologize and get on with life. Do not beat up yourself, and certainly do not beat up others for your mistake. Do not waste time on embarrassment or recrimination, just fix the problem and move on.
Ask for help. Seek out (and give) peer reviews. One of the ways open source software is supposed to excel is in the number of eyeballs applied to it; this does not apply if nobody will review code.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.