Contributed by Poul-Henning Kamp <phk@FreeBSD.org> and David O'Brien <obrien@FreeBSD.org>.
June 1996.
在 FreeBSD 系統中有若干部份的軟體是由 FreeBSD 之外的計畫所維護的。 為了歷史上的理由，我們稱之為 捐助 (contributed) 軟體。例如 perl、gcc 以及 patch。
在過去的數年間，有數個方法被使用在處理這些型態的軟體， 且各有其優缺點。這些方法中並沒有任何一個具有明顯的優勢。
在這樣的情形下，經過若干的討論之後， 下面的方式被選擇為未來引進此類軟體的 "正式 (official)" 的方式。進一步來說， 我們強烈的認為現有的捐助軟體應該隨著時間改變成這樣的模式， 因為他跟舊有方式相比有明顯的優點， 包括能夠容易的由任何人取得此類軟體"正式"版本的修政檔案 (即使沒有該軟體 cvs 的存取權)。 這將會使得回到該捐助軟體的主要發展版本的修正變的容易。
然而最後，仍然是回到真正處理這項工作的人。 如果使用這個模式對於該項軟體的處理是極度的不洽當， 在核心小組以及其他發展者的一致同意下，仍然可以有例外。 是否有在未來維護該軟體的可能是處理此類事件的關鍵因素。
Note: 由於 RCS 檔案格式的若干不幸的設計上的極限以及 CVS 對於 vendor branches 的使用， 對於那些仍然在 vendor branches 追蹤下的檔案， 次要的或是不具意義的，以及/或是修飾性的更正是被 強烈制止的。 "錯字的修正" 在此被明顯的歸類在 "修飾性" 更正的類別， 在版本編號 1.1.x.x 的檔案中是不應該出現的。 CVS 倉庫因為一個字元的修正而造成的膨脹是非常的戲劇化的。
TCL 內嵌式程式語言將會被用來說明這個模式的運用：
src/contrib/tcl 包含了由這個軟體的維護者發行的程式碼。程式碼中完全與 FreeBSD 無關的部分是可以被移除的。對 Tcl 來說， mac，win 以及 compat 子目錄在 import 進 CVS 之前就已經被刪去了。
src/lib/libtcl 只包含了一個 "bmake 型態" 的 Makefile，該檔使用標準的 bsd.lib.mk 檔案中的規則來產生程式庫以及安裝文件。
src/usr.bin/tclsh 只包含了一個 bmake 形態 Makefile，改檔案會使用儲存在 bsd.prog.mk 檔案中標準的規則來產生及安裝 tclsh 程式以及相關的 man-page。
src/tools/tools/tcl_bmake 包含了一組 在 tcl 軟體需要升級時有用的 shell-scripts。 那些並不是所建立或是安裝得軟體的一部分。
這其中的重點是 src/contrib/tcl 目錄是依照下列法則建立的：此目錄應該存有原先發行的程式碼 (在適當的 CVS vendor-branch 以及沒有 RCS 關鍵字的展開) 進可能包含最少 FreeBSD 專用的修改。在 freefall 上的 'easy-import' 程式將會在你處理 import 時給你幫助， 但對於如何處理若仍有任何懷疑，你務必應該先問問別人， 而非愚蠢的就先試了再說而希望可以 "試出來"。 CVS 對於一個錯誤的 import 意外是不饒人的， 需要相當份量的努力才能在一個關鍵性的錯誤中回到原先的狀態。
由於前面提過的 CVS 在處理 vendor branches 的設計上的限制， 對於由 vendor branches 發行的 "正式 (official)" 的 patches，應該將其 patch 到其原來的發行的程式碼上， 然後再次的 import 到該 vendor brench。正式的 patches 決對不應該作用在從 FreeBSD CVS 中取出 (check out) 的版本上然後再 commit 進 CVS，這樣會破壞 verndor branch 的一致性， 並且使得下次引進 (import) 新版本便得困難，因為會有衝突 (conflicts)。
在許多的軟體中包含了許多為了與 FreeBSD 以外的系統相容的檔案， 為了節省硬碟空間而從原來的軟體程式碼中移去這些檔案是被允許的。 而那些包含有版權宣告以及版本相關的資訊及相關的文件檔案， 對於那些有用的程式碼來說是有用的，這些檔案 不應該 被移去。
所需要的 bmake Makefiles 有時可以用一些工具自動地由各軟體的檔案目錄的產生， 這會使得這些軟體的升級變得更加得容易。如果有這樣的工具程式的話， 確定你有將這些工具(如果有必要的話)放入 src/tools 目錄中，這樣以後維護軟體的人們就可以使用。
在 src/contrib/tcl 目錄下，你應該加入 一個名叫 FREEBSD-upgrade 的檔案， 檔案中包括：
那些檔案應該在 import 前被移去
原始的版本應該的正式的發行站台為何？
若有修正 patches 應該送去哪位原軟體作者。
或許在加入若干針對 FreeBSD 所做的修改的說明。
然而，請不要與原有的程式碼一起將 FREEBSD-upgrade import 進 CVS。 你應該在最初的 import 之後，使用 cvs add FREEBSD-upgrade ; cvs ci。由 src/contrib/cpio 目錄下取得的例子是這樣的：
This directory contains virgin sources of the original distribution files
on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
the files in this directory via patches and a cvs commit. New versions or
official-patch versions must be imported. Please remember to import with
"-ko" to prevent CVS from corrupting any vendor RCS Ids.
For the import of GNU cpio 2.4.2, the following files were removed:
INSTALL cpio.info mkdir.c
Makefile.in cpio.texi mkinstalldirs
To upgrade to a newer version of cpio, when it is available:
1. Unpack the new version into an empty directory.
[Do not make ANY changes to the files.]
2. Remove the files listed above and any others that don't apply to
FreeBSD.
3. Use the command:
cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
src/contrib/cpio GNU cpio_<version>
For example, to do the import of version 2.4.2, I typed:
cvs import -ko -m 'Virgin import of GNU v2.4.2' \
src/contrib/cpio GNU cpio_2_4_2
4. Follow the instructions printed out in step 3 to resolve any
conflicts between local FreeBSD changes and the newer version.
Do not, under any circumstances, deviate from this procedure.
To make local changes to cpio, simply patch and commit to the main
branch (aka HEAD). Never make local changes on the GNU branch.
All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
inclusion in the next vendor release.
obrien@FreeBSD.org - 30 March 1997