os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Minor wordsmithing to reflect current practice

Browse source 
Generally things are done by consensus, with the core team stepping in when
there's a dispute. Update the documented encumbered software policy to reflect
what's actually done and is considered to be working. This harmonizes the wording
for contributed software and encumbered software. Also wordsmith how Release
Engineering is referenced. Also removes stray > marks on object files. Also
document the fw files.

Note: the ascii file requierment dates from CVS days and should change. But
I've not pushed things that far in this commit.
This commit is contained in:
Warner Losh 2021-02-04 11:34:25 -07:00
parent 612d995019
commit e2223b82bd
1 changed files with 7 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
documentation/content/en/books/developers-handbook/policies/chapter.adoc
View file

@ -70,7 +70,7 @@ Over the last couple of years, various methods have been used in dealing with th
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.
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]
====
@ -307,15 +307,16 @@ It might occasionally be necessary to include an encumbered file in the FreeBSD
. 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>#.
. 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 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.
.. 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`.
.. The link:https://www.FreeBSD.org/administration/#t-re[Release Engineering] decides if it goes into the release.
.. 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