diff --git a/documentation/content/en/books/developers-handbook/policies/chapter.adoc b/documentation/content/en/books/developers-handbook/policies/chapter.adoc index bd3eec64bb..0f437fd48c 100644 --- a/documentation/content/en/books/developers-handbook/policies/chapter.adoc +++ b/documentation/content/en/books/developers-handbook/policies/chapter.adoc @@ -1,330 +1,271 @@ --- 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 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. ==== -[[vendor-import-git]] -=== Vendor Imports with Git +[[vendor-import-svn]] +=== Vendor Imports with SVN -This section describes the vendor import procedure with git in detail. - -[.conventions] -. *Branch naming convention* -All vendor branches and tags start with `vendor/` and are branches and -tags visible by default. Prior drafts of this document had them directly under -`refs/vendor` rather than `refs/heads/vendor` and `refs/tags/vendor` (the git -defaults) so early adopters that have the older refs may need to clean them up. - -[NOTE] -==== -This chapter follows the convention that the `freebsd` origin is the source of truth. If you use a different convention, replace `freebsd` with your name as appopriate. -==== - - -We'll explore an example for updating NetBSD's mtree that's in our -tree. The vendor branch for this is `vendor/NetBSD/mtree`. +This section describes the vendor import procedure with Subversion in details. [.procedure] -. *Updating an old vendor import* -Since the trees we have in vendor branches are usually a tiny subset of -the FreeBSD, it's best to do them with work trees since the process is -quite fast. Make sure that whatever directory you choose (the -`../mtree`) argument is empty and doesn't conflict. -[source,bash] -.... -% git worktree add ../mtree vendor/NetBSD/mtree -.... -. *Update the Sources in the Vendor Branch* +. *Preparing the Tree* + -Prepare a full, clean tree of the vendor sources. Import everything but merge only what is needed. +If this is your first import after the switch to SVN, you will have to flatten and clean up the vendor tree, and bootstrap merge history in the main tree. If not, you can safely omit this step. ++ +During the conversion from CVS to SVN, vendor branches were imported with the same layout as the main tree. For example, the foo vendor sources ended up in [.filename]#vendor/foo/dist/contrib/foo#, but it is pointless and rather inconvenient. What we really want is to have the vendor source directly in [.filename]#vendor/foo/dist#, like this: + -I have my copy of NetBSD checked out from their GitHub mirror in -`~/git/NetBSD`, so I'll update from there: Note that "upstream" might -have added or removed files, so we want to make sure deletions are -propagated as well. rsync(1) is commonly installed, so I'll use that. [source,bash] .... -% cd ../mtree -% rsync -va --del --exclude=".git" ~/git/NetBSD/usr.sbin/mtree/ . -% git add -A -% git status -... -% git diff --staged -... -% git commit -m"Vendor import of NetBSD's mtree at 2020-12-11" -[vendor/NetBSD/mtree 8e7aa25fcf1] Vendor import of NetBSD's mtree at 2020-12-11 - 7 files changed, 114 insertions(+), 82 deletions(-) -% git tag -a vendor/NetBSD/mtree/20201211 +% cd vendor/foo/dist/contrib/foo +% svn move $(svn list) ../.. +% cd ../.. +% svn remove contrib +% svn propdel -R svn:mergeinfo +% svn commit .... ++ +Note that, the `propdel` bit is necessary because starting with 1.5, Subversion will automatically add `svn:mergeinfo` to any directory you copy or move. In this case, you will not need this information, since you are not going to merge anything from the tree you deleted. + -Note: I run the `git diff` and `git status` commands to make sure nothing weird -was present. Also I used `-m` to illustrate, but you should compose a proper -message in an editor (using a commit message template). +[NOTE] +==== +You may want to flatten the tags as well. The procedure is exactly the same. If you do this, put off the commit until the end. +==== ++ +Check the [.filename]#dist# tree and perform any cleanup that is deemed to be necessary. You may want to disable keyword expansion, as it makes no sense on unmodified vendor code. In some cases, it can be even be harmful. + -It's also important to create an annotated tag, otherwise the push -will be rejected. Only annotated tags are allowed to be pushed. -. *Updating the FreeBSD Copy* -At this point you can push the import to vendor into our repo. [source,bash] .... -% git push --follow-tags freebsd vendor/NetBSD/mtree +% svn propdel svn:keywords -R . +% svn commit .... - -`--follow-tags` tells `git push` to also push tags associated with the locally committed revision. -. *Updating the FreeBSD source tree* -Now you need to update the mtree in FreeBSD. The sources live in -`contrib/mtree` since it is upstream software. -[source,bash] -.... -% cd ../src -% git subtree merge -P contrib/mtree vendor/NetBSD/mtree -.... -This would generate a subtree merge commit of `contrib/mtree` against the local `vendor/NetBSD/mtree` branch. If there were conflicts, you would need to fix them before committing. -+ -. *Rebasing your change against latest FreeBSD source tree* -Because the current policy recommends against using merges, if the upstream FreeBSD `main` moved forward -before you get a chance to push, you would have to redo the merge. -+ -Regular `git rebase` or `git pull --rebase` doesn't know how to rebase a merge commit **as a merge commit**, -so instead of that you would have to recreate the commit. -+ -The easiest way to do this would be to create a side branch with the **contents** of the merged tree: ++ +Bootstrapping of `svn:mergeinfo` on the target directory (in the main tree) to the revision that corresponds to the last change was made to the vendor tree prior to importing new sources is also needed: + [source,bash] .... -% cd ../src -% git fetch freebsd -% git checkout -b merge_result -% git merge freebsd/main +% cd head/contrib/foo +% svn merge --record-only ^/vendor/foo/dist@12345678 . +% svn commit .... ++ +With some shells, the `^` in the above command may need to be escaped with a backslash. +. *Importing New Sources* ++ +Prepare a full, clean tree of the vendor sources. With SVN, we can keep a full distribution in the vendor tree without bloating the main tree. Import everything but merge only what is needed. ++ +Note that you will need to add any files that were added since the last vendor import, and remove any that were removed. To facilitate this, you should prepare sorted lists of the contents of the vendor tree and of the sources you are about to import: + -Typically, there would be no merge conflicts here (because developers tends to work on different components). -In the worst case scenario, you would still have to resolve merge conflicts, if there was any, but this -should be really rare. -+ -Now, checkout `freebsd/main` again as `new_merge`, and redo the merge: -[source,bash] -.... -% git checkout -b new_merge freebsd/main -% git subtree merge -P contrib/mtree vendor/NetBSD/mtree -.... -Instead of resolving the conflicts, perform this instead: [source,bash] .... -% git checkout merge_result . +% cd vendor/foo/dist +% svn list -R | grep -v '/$' | sort > ../old +% cd ../foo-9.9 +% find . -type f | cut -c 3- | sort > ../new .... -Which will overwrite the files with conflicts with the version found in `merge_result`. ++ +With these two files, the following command will list removed files (files only in [.filename]#old#): + -Examine the tree against `merge_result` to make sure that you haven't missed deleted files: [source,bash] .... -% git diff merge_result +% comm -23 ../old ../new .... -. *Creating a new vendor branch* -There's a number of ways to create a new vendor branch. The easiest is -to create a new repository and then merge that with FreeBSD. Let's say -we're importing `glorbnitz` into the FreeBSD tree, release 3.1415. For -the sake of simplicity, we'll not trim this release. It's a user -command that puts the nitz device into different magical glorb states. ++ +While the command below will list added files (files only in [.filename]#new#): + -. *Create the repo* [source,bash] .... -% cd /some/where -% mkdir glorbnitz -% cd glorbnitz -% git init -% git checkout -b vendor/glorbnitz +% comm -13 ../old ../new .... -At this point, you have a new repo, where all new commits will go on -the `vendor/glorbnitz` branch. -+ -(Git professionals can also do this right in their FreeBSD clone, if they know -how to create a new root commit that's not attached to anything, e.g. -`git checkout --orphan vendor/glorbnitz`) ++ +Let us put this together: + -. *Copy the sources in* -Since this is a new import, you can just cp the sources in, or use tar or -even rsync as shown above. And we'll add everything, assuming no dot files. [source,bash] .... -% cp -r ~/glorbnitz/* . -% git add * +% cd vendor/foo/foo-9.9 +% tar cf - . | tar xf - -C ../dist +% cd ../dist +% comm -23 ../old ../new | xargs svn remove +% comm -13 ../old ../new | xargs svn add .... + -At this point, you should have a pristine copy of glorbnitz ready to commit. +[WARNING] +==== + +If there are new directories in the new distribution, the last command will fail. You will have to add the directories, and run it again. Conversely, if any directories were removed, you will have to remove them manually. +==== ++ +Check properties on any new files: + +** All text files should have `svn:eol-style` set to `native`. +** All binary files should have `svn:mime-type` set to `application/octet-stream`, unless there is a more appropriate media type. +** Executable files should have `svn:executable` set to `*`. +** There should be no other properties on any file in the tree. + -[source,bash] -.... -% git commit -m"Import GlorbNitz frobnosticator revision 3.1415" -.... -As above, I used `-m` for simplicity, but you should likely create a -commit message that explains what a Glorb is and why you'd use a Nitz -to get it. Not everybody will know. +[NOTE] +==== +You are ready to commit, but you should first check the output of `svn stat` and `svn diff` to make sure everything is in order. +==== ++ +Once you have committed the new vendor release, you should tag it for future reference. The best and quickest way is to do it directly in the repository: + -. *Now import it into our repository* -Now you need to import the branch into our repository. [source,bash] .... -% cd /path/to/freebsd/repo/src -% git remote add glorbnitz /some/where/glorbnitz -% git fetch glorbnitz vendor/glorbnitz +% svn copy ^/vendor/foo/dist svn_base/vendor/foo/9.9 .... -Note the vendor/glorbnitz branch is in the repo. At this point the -`/some/where/glorbnitz` can be deleted, if you like. It was only a means -to an end. ++ +To get the new tag, you can update your working copy of [.filename]#vendor/foo#. ++ +[NOTE] +==== +If you choose to do the copy in the checkout instead, do not forget to remove the generated `svn:mergeinfo` as described above. +==== + +. *Merging to __-HEAD__* ++ +After you have prepared your import, it is time to merge. Option `--accept=postpone` tells SVN not to handle merge conflicts yet, because they will be taken care of manually: + -. *Tag and push* -Steps from here on out are much the same as they are in the case of -updating a vendor branch, though w/o the updating the vendor -branch step. [source,bash] .... -% git worktree add ../glorbnitz vendor/glorbnitz -% cd ../glorbnitz -% git tag --annotate vendor/glorbnitz/3.1415 -# Make sure it's good -% git push --follow-tags freebsd vendor/glorbnitz +% cd head/contrib/foo +% svn update +% svn merge --accept=postpone ^/vendor/foo/dist .... -By 'good' we mean: -1. All the right files are present -2. None of the wrong files are present -3. The vendor branch points at something sensible -4. The tag looks good, and is annotated. ++ +Resolve any conflicts, and make sure that any files that were added or removed in the vendor tree have been properly added or removed in the main tree. It is always a good idea to check differences against the vendor branch: + -. *Time to finally merge it into the base tree* [source,bash] .... -% cd ../src -% git subtree add -P contrib/glorbnitz vendor/glorbnitz -# Make sure it's good -% git push freebsd +% svn diff --no-diff-deleted --old=^/vendor/foo/dist --new=. .... -Here 'good' means: -1. All the right files, and none of the wrong ones, were merged into contrib/glorbnitz. -2. No other changes are in the tree -3. The commit messages look good. ++ +`--no-diff-deleted` tells SVN not to check files that are in the vendor tree but not in the main tree. + [NOTE] -=== -This hasn't connected `glorbnitz` to the build yet. How to do -that hasn't changed and is beyond the scope of this article. -=== +==== +With SVN, there is no concept of on or off the vendor branch. If a file that previously had local modifications no longer does, just remove any left-over cruft, such as FreeBSD version tags, so it no longer shows up in diffs against the vendor tree. +==== ++ +If any changes are required for the world to build with the new sources, make them now - and test until you are satisfied that everything build and runs correctly. +. *Commit* ++ +Now, you are ready to commit. Make sure you get everything in one go. Ideally, you would have done all steps in a clean tree, in which case you can just commit from the top of that tree. That is the best way to avoid surprises. If you do it properly, the tree will move atomically from a consistent state with the old code to a consistent state with the new code. + [[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>#. . Kernel files: .. Should always be referenced in [.filename]#conf/files.*# (for build simplicity). .. Should always be in [.filename]#LINT#, but the link:https://www.FreeBSD.org/administration/#t-core[Core Team] decides per case if it should be commented out or not. The link:https://www.FreeBSD.org/administration/#t-core[Core Team] can, of course, change their minds later on. .. The _Release Engineer_ 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`. .. The link:https://www.FreeBSD.org/administration/#t-re[Release Engineering] 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. The three principles of shared library building are: * Start from `1.0` * If there is a change that is backwards compatible, bump minor number (note that ELF systems ignore the minor number) * If there is an incompatible change, bump major number For instance, added functions and bugfixes result in the minor version number being bumped, while deleted functions, changed function call syntax, etc. will force the major version number to change. Stick to version numbers of the form major.minor (`_x_._y_`). Our a.out dynamic linker does not handle version numbers of the form `_x_._y_._z_` well. Any version number after the `_y_` (i.e., the third digit) is totally ignored when comparing shared lib version numbers to decide which library to link with. Given two shared libraries that differ only in the "micro" revision, `ld.so` will link with the higher one. That is, if you link with [.filename]#libfoo.so.3.3.3#, the linker only records `3.3` in the headers, and will link with anything starting with `_libfoo.so.3_._(anything >= 3)_._(highest available)_`. [NOTE] ==== `ld.so` will always use the highest "minor" revision. For instance, it will use [.filename]#libc.so.2.2# in preference to [.filename]#libc.so.2.0#, even if the program was initially linked with [.filename]#libc.so.2.0#. ==== In addition, our ELF dynamic linker does not handle minor version numbers at all. However, one should still specify a major and minor version number as our [.filename]#Makefile#'s "do the right thing" based on the type of system. For non-port libraries, it is also our policy to change the shared library version number only once between releases. In addition, it is our policy to change the major shared library version number only once between major OS releases (i.e., from 6.0 to 7.0). When you make a change to a system library that requires the version number to be bumped, check the [.filename]#Makefile#'s commit logs. It is the responsibility of the committer to ensure that the first such change since the release will result in the shared library version number in the [.filename]#Makefile# to be updated, and any subsequent changes will not.