git: 7e775c6d1a - main - dev-handbook: update description of contrib software

From: Mitchell Horne <>
Date: Fri, 20 Oct 2023 15:16:18 UTC
The branch main has been updated by mhorne:


commit 7e775c6d1a9f5629bcb8a54cf0e70b53b1aca7de
Author:     Mitchell Horne <>
AuthorDate: 2023-10-20 15:14:38 +0000
Commit:     Mitchell Horne <>
CommitDate: 2023-10-20 15:15:56 +0000

    dev-handbook: update description of contrib software
    The existing description reflects a time when the process for managing
    contrib software was less standardized. Provide a brief description of
    how we manage vendor branches, with some conventions.
    Reviewed by:    carlavilla, imp, emaste
    Sponsored by:   The FreeBSD Foundation
    Differential Revision:
 .../en/books/developers-handbook/policies/_index.adoc  | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/documentation/content/en/books/developers-handbook/policies/_index.adoc b/documentation/content/en/books/developers-handbook/policies/_index.adoc
index 93a034458c..cbd8707022 100644
--- a/documentation/content/en/books/developers-handbook/policies/_index.adoc
+++ b/documentation/content/en/books/developers-handbook/policies/_index.adoc
@@ -87,18 +87,18 @@ The role of the maintainer is as follows:
 Some parts of the FreeBSD distribution consist of software that is actively being maintained outside the FreeBSD project.
 For historical reasons, we call this _contributed_ software.
-Some examples are sendmail, gcc and patch.
+Some examples are LLVM, man:zlib[3], and man:awk[1].
-Over the last couple of years, various methods have been used in dealing with this type of software and all have some number of advantages and drawbacks.
-No clear winner has emerged.
+The accepted procedure for managing contributed software involves creating a _vendor branch_, where the software can be imported cleanly (without modification) and updates can be tracked in a versioned manner.
+Then, the content of the vendor branch is applied to the source tree, possibly with local modifications.
+FreeBSD-specific build glue is maintained in the source tree, not in the vendor branch.
-Since this is the case, after some debate one of these methods has been selected as the "official" method and will be required for future imports of software of this kind.
-Furthermore, it is strongly suggested that existing contributed software converge on this model over time, as it has significant advantages over the old method, including the ability to easily obtain diffs relative to the "official" versions of the source by everyone (even without direct repository access).
-This will make it significantly easier to return changes to the primary developers of the contributed software.
+Depending on their needs and complexity, individual software projects may deviate from this procedure, at the discretion of the maintainer.
+The exact steps required to update a particular piece of contributed software should be recorded in a file named `FREEBSD-upgrade`;
+for example, link:[libarchive's FREEBSD-upgrade file].
-Ultimately, however, it comes down to the people actually doing the work.
-If using this model is particularly unsuited to the package being dealt with, exceptions to these rules may be granted only with the approval of the core team and with the general consensus of the other developers.
-The ability to maintain the package in the future will be a key issue in the decisions.
+Contributed software is usually placed in the [.filepath]#contrib/# subdirectory of the source tree, with some exceptions.
+Contributed software used only by the kernel lives under [.filepath]#sys/contrib/#.