If you are 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. If you see 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. If, however, you are
about to modify something which is clearly being actively
maintained by someone else (and it is only by watching the
mailing list that you can really get a feel for just what is and
is not) then consider sending the change to them instead, just
as you would have before becoming a committer. For ports, you
should contact the listed repository
-committersMAINTAINER
in the
Makefile
. For other parts of the
repository, if you are unsure who the active maintainer might
be, it may help to scan the revision history to see who has
committed changes in the past. Bill Fenner <fenner@FreeBSD.org>
has written a nice
shell script that can help determine who the active maintainer
might be. It lists each person who has committed to a given
file along with the number of commits each person has made. It
can be found on freefall
at
~fenner/bin/whodid
. If your queries go
unanswered or the committer otherwise indicates a lack of
interest in the area affected, go ahead and commit it.
If you are unsure about a commit for any reason at
all, have it reviewed by -hackers
before committing. Better to have it flamed then and there
rather than when it is part of the repository. If you do
happen to commit something which results in controversy
erupting, you may also wish 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 someone you disagree with. If they see a different solution to a problem than you, or even a different problem, it is not because they are stupid, because they have questionable parentage, or because they are trying to destroy your hard work, personal image, or FreeBSD, but simply 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.
This, and other documents, can be downloaded from http://ftp.FreeBSD.org/pub/FreeBSD/doc/
For questions about FreeBSD, read the
documentation before
contacting <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.