diff --git a/documentation/content/en/books/developers-handbook/policies/chapter.adoc b/documentation/content/en/books/developers-handbook/policies/chapter.adoc index d6465e51ff..5893cbf682 100644 --- a/documentation/content/en/books/developers-handbook/policies/chapter.adoc +++ b/documentation/content/en/books/developers-handbook/policies/chapter.adoc @@ -1,139 +1,139 @@ --- title: Chapter 5. Source Tree Guidelines and Policies authors: - author: Poul-Henning Kamp - author: Giorgos Keramidas prev: books/developers-handbook/l10n next: books/developers-handbook/testing --- [[policies]] = Source Tree Guidelines and Policies :doctype: book :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :skip-front-matter: :xrefstyle: basic :relfileprefix: ../ :outfilesuffix: :sectnumoffset: 5 include::shared/mirrors.adoc[] include::shared/authors.adoc[] include::shared/releases.adoc[] include::shared/en/mailing-lists.adoc[] include::shared/en/teams.adoc[] include::shared/en/urls.adoc[] toc::[] This chapter documents various guidelines and policies in force for the FreeBSD source tree. [[policies-style]] == Style Guidelines Consistent coding style is extremely important, particularly with large projects like FreeBSD. Code should follow the FreeBSD coding styles described in man:style[9] and man:style.Makefile[5]. [[policies-maintainer]] == `MAINTAINER` on Makefiles If a particular portion of the FreeBSD [.filename]#src/# distribution is being maintained by a person or group of persons, this is communicated through an entry in [.filename]#src/MAINTAINERS#. Maintainers of ports within the Ports Collection express their maintainership to the world by adding a `MAINTAINER` line to the [.filename]#Makefile# of the port in question: [.programlisting] .... MAINTAINER= email-addresses .... [TIP] ==== For other parts of the repository, or for sections not listed as having a maintainer, or when you are unsure who the active maintainer is, try looking at the recent commit history of the relevant parts of the source tree. It is quite often the case that a maintainer is not explicitly named, but the people who are actively working in a part of the source tree for, say, the last couple of years are interested in reviewing changes. Even if this is not specifically mentioned in the documentation or the source itself, asking for a review as a form of courtesy is a very reasonable thing to do. ==== The role of the maintainer is as follows: * The maintainer owns and is responsible for that code. This means that he or she is responsible for fixing bugs and answering problem reports pertaining to that piece of the code, and in the case of contributed software, for tracking new versions, as appropriate. * Changes to directories which have a maintainer defined shall be sent to the maintainer for review before being committed. Only if the maintainer does not respond for an unacceptable period of time, to several emails, will it be acceptable to commit changes without review by the maintainer. However, it is suggested that you try to have the changes reviewed by someone else if at all possible. * It is of course not acceptable to add a person or group as maintainer unless they agree to assume this duty. On the other hand it does not have to be a committer and it can easily be a group of people. [[policies-contributed]] == Contributed Software 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. 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. 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. 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 link:https://www.FreeBSD.org/administration/#t-core[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. [NOTE] ==== Because it makes it harder to import future versions minor, trivial and/or cosmetic changes are _strongly discouraged_ on files that are still tracking the vendor branch. ==== -For details on how do do a vendor import please see link:http://www.FreeBSD.org/en/articles/committers-guide/#git-primer[the committers guide] +For details on how do do a vendor import please see link:https://docs.freebsd.org/en/articles/committers-guide/#git-primer#git-primer[the committers guide] [[policies-encumbered]] == Encumbered Files It might occasionally be necessary to include an encumbered file in the FreeBSD source tree. For example, if a device requires a small piece of binary code to be loaded to it before the device will operate, and we do not have the source to that code, then the binary file is said to be encumbered. The following policies apply to including encumbered files in the FreeBSD source tree. . Any file which is interpreted or executed by the system CPU(s) and not in source format is encumbered. . Any file with a license more restrictive than BSD or GNU is encumbered. . A file which contains downloadable binary data for use by the hardware is not encumbered, unless (1) or (2) apply to it. It must be stored in an architecture neutral ASCII format (file2c or uuencoding is recommended). . Any encumbered file requires specific approval from the link:https://www.FreeBSD.org/administration/#t-core[Core Team] before it is added to the repository. . Encumbered files go in [.filename]#src/contrib# or [.filename]#src/sys/contrib#. . The entire module should be kept together. There is no point in splitting it, unless there is code-sharing with non-encumbered code. . Object files are named [.filename]#arch/filename.o.uu#. . Firmware files are named [.filename]#filename.fw.uu#. . Kernel files: .. Should always be referenced in [.filename]#conf/files.*# (for build simplicity). .. Should always be in [.filename]#LINT#, but when the consensus isn't clear the link:https://www.FreeBSD.org/administration/#t-core[Core Team] decides if it should be commented out or not. .. The link:https://www.FreeBSD.org/administration/#t-re[Release Engineering] team decides whether or not it goes into the release. . User-land files: .. The link:https://www.FreeBSD.org/administration/#t-core[Core team] decides if the code should be part of `make world` by default if there is no clear consensus. .. The link:https://www.FreeBSD.org/administration/#t-re[Release Engineering] team decides if it goes into the release. [[policies-shlib]] == Shared Libraries If you are adding shared library support to a port or other piece of software that does not have one, the version numbers should follow these rules. Generally, the resulting numbers will have nothing to do with the release version of the software. FreeBSD tries to maintain ABI stability. Most libraries in the system use symbol versioning to remain compatible with old versions of the library. When updating libraries with versioned symbols: . Create new symbols in the symbol map for otherwise incompatible changes. . When deleting old functions, only remove visibility of symbols from newer versions (that is, do not delete functions). . Avoid gratuitous rearrangement of structures. This will keep compatibility symbols to a minimum. . If changes require a version bump, re-evaluate whether they are needed at all. For project-maintained libraries, please try to follow the following guidelines for major version numbers: . New libraries .. Should start with major version 1, though third-party libraries may start at a different number if warranted .. All new libraries should either be symvers or private unless there's some compelling reason to deviate. . For non-symvers libraries, avoid changes that would require a version bump. .. When making a change that requires one, seriously consider adopting symbol versions at the same time . For symvers libraries, generally, avoid version bumps . Changes to structures can be worked around by providing the old structure and old functions to access it (if the layout of the structure is embedded in its clients). . Changes to function signatures can be implemented by creating compatibility versions of the function (often calling the new version of the function in a specific way). . If the benefits of a version bump outweight the costs to do it, follow up to ensure compat packages are built, etc . Carefully consider the impact of a major version bump. When a major version change cannot be avoided, add a version map to avoid future bumps. . For libraries where the ABI cannot be guaranteed, make them FreeBSD private where possible. Third party libraries that have poor ABI guarantees are generally made private, though there are a few exceptions for historical reasons. . It is strong policy not to change the ABI of dynamicly linked libararies in an non-backwards compatible way . Every reasonable effort should be made to make the changes in a binary compatible manner using tools like symbol versioning . When major version changes cannot be avoided, the policy is to change only between major releases. .. Minimize the number of major version bumps where possible .. Multiple bumps are allowed between releases where necessary .. Where possible, batch multiple changes that each would require a major bump together .. Ensure that the compatibility ports / packages are updated as appropriate .. Request an exp-run of ports to understand the full impact of the change to the base system . Any changes to major libraries must still allow build from source upgrades to succeed Changing the ABI is allowed, otherwise FreeBSD cannot evolve. However, the project has generally chosen to pay the added cost of retaining ABI backward-compatibility.