> It might be nice to explain this in a bit more depth -- possibly using the
> phrase "code rot". That is, it's broken not just because of policy, but
> because it loses relevance, and tends to go unmaintained, results in
> confusion, etc.
I was trying to avoid getting too philosophical, but OK -- here's a
revised stab:
7.5 Unreferenced File Policy
============================
An "unreferenced file" is a file that is not used during a build of a
given source tree. Because unreferenced files will "rot" over time and
lose relevance, and may indicate brokenness in the build process itself
(such as a mistakenly-unused packaging dependency file), such files are
forbidden in the ON source tree. However, exceptions may be granted by
the gatekeepers when appropriate -- usually for:
* READMEs and other textfiles that aid in understanding the source.
(Exceptions for these are automatically granted, provided the files
end in ".txt".)
* Source that's used during "specialized" builds, such as CRYPT_SRC,
EXPORT_SRC -- or by tools that have not yet been tied into the build,
such as warlock.
* Source subtrees that will likely be resynched with an upstream entity
(e.g., sqlite). (This exception does not extend to unused build
infrastructure: upstream Makefiles and other unused build files are
forbidden since they are a hazard to those maintaining ON's actual
build infrastructure.)
The detection of unreferenced files in ON is automated by the findunref
tool (see http://opensolaris.org/os/community/on/findunref). To ensure
that findunref only flags valid unreferenced files, any granted exceptions
must be listed in usr/src/tools/findunref/exception_list.
--
meem
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
