diff --git a/en/handbook/policies/chapter.sgml b/en/handbook/policies/chapter.sgml index f1945b288d..76f8f4f2d6 100644 --- a/en/handbook/policies/chapter.sgml +++ b/en/handbook/policies/chapter.sgml @@ -1,7 +1,7 @@ @@ -218,6 +218,98 @@ inclusion in the next vendor release. obrien@freebsd.org - 30 March 1997 + + + 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 Core team before it is added to the + CVS repository. + + + + Encumbered files go in src/contrib or + 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 + arch/filename.o.uu>. + + + + Kernel files; + + + + Should always be referenced in + conf/files.* (for build simplicity). + + + + Should always be in LINT, but the Core team decides per case if it + should be commented out or not. The Core team can, of course, change + their minds later on. + + + + The Release Engineer + decides whether or not it goes in to the release. + + + + + + User-land files; + + + + The Core team decides if + the code should be part of make world. + + + + The Release Engineer + decides if it goes in to the release. + + + + + Shared Libraries diff --git a/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml b/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml index f1945b288d..76f8f4f2d6 100644 --- a/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml +++ b/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml @@ -1,7 +1,7 @@ @@ -218,6 +218,98 @@ inclusion in the next vendor release. obrien@freebsd.org - 30 March 1997 + + + 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 Core team before it is added to the + CVS repository. + + + + Encumbered files go in src/contrib or + 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 + arch/filename.o.uu>. + + + + Kernel files; + + + + Should always be referenced in + conf/files.* (for build simplicity). + + + + Should always be in LINT, but the Core team decides per case if it + should be commented out or not. The Core team can, of course, change + their minds later on. + + + + The Release Engineer + decides whether or not it goes in to the release. + + + + + + User-land files; + + + + The Core team decides if + the code should be part of make world. + + + + The Release Engineer + decides if it goes in to the release. + + + + + Shared Libraries diff --git a/en_US.ISO8859-1/books/handbook/policies/chapter.sgml b/en_US.ISO8859-1/books/handbook/policies/chapter.sgml index f1945b288d..76f8f4f2d6 100644 --- a/en_US.ISO8859-1/books/handbook/policies/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/policies/chapter.sgml @@ -1,7 +1,7 @@ @@ -218,6 +218,98 @@ inclusion in the next vendor release. obrien@freebsd.org - 30 March 1997 + + + 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 Core team before it is added to the + CVS repository. + + + + Encumbered files go in src/contrib or + 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 + arch/filename.o.uu>. + + + + Kernel files; + + + + Should always be referenced in + conf/files.* (for build simplicity). + + + + Should always be in LINT, but the Core team decides per case if it + should be commented out or not. The Core team can, of course, change + their minds later on. + + + + The Release Engineer + decides whether or not it goes in to the release. + + + + + + User-land files; + + + + The Core team decides if + the code should be part of make world. + + + + The Release Engineer + decides if it goes in to the release. + + + + + Shared Libraries diff --git a/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml b/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml index f1945b288d..76f8f4f2d6 100644 --- a/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml +++ b/en_US.ISO_8859-1/books/handbook/policies/chapter.sgml @@ -1,7 +1,7 @@ @@ -218,6 +218,98 @@ inclusion in the next vendor release. obrien@freebsd.org - 30 March 1997 + + + 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 Core team before it is added to the + CVS repository. + + + + Encumbered files go in src/contrib or + 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 + arch/filename.o.uu>. + + + + Kernel files; + + + + Should always be referenced in + conf/files.* (for build simplicity). + + + + Should always be in LINT, but the Core team decides per case if it + should be commented out or not. The Core team can, of course, change + their minds later on. + + + + The Release Engineer + decides whether or not it goes in to the release. + + + + + + User-land files; + + + + The Core team decides if + the code should be part of make world. + + + + The Release Engineer + decides if it goes in to the release. + + + + + Shared Libraries