svn commit: r345138 - head/share/man/man9

[Ed Maste]

On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes
<freebsd at gndrsh.dnsmgr.net> wrote:
>
> > The reason not to do it is uuencoding adds about a 40% space penalty,
> > adds to the build time (to uudecode), and makes changes harder to
> > review. In my mind dropping the unnecessary uuencoding is similar to
> > dropping build-time patching of files in the source tree (another
> > workaround we used to have for limitations of our older VCS).
>
> I think I covered all the above in other replies.

So:
1. We used to use a VCS which does not support binary files well, but
have not used it for years.
2. Another source delivery tool (ctm) previously did not support
binary files, but has for some time.
3. There may have been other reasons, but none that anyone can recall
(at present).

> > Yes, we should look at the other cases where we unnecessarily uuencode
> > things. I'm not quite sure where we would document high level things
> > like this though, do you have a suggestion?  I could see a case for
> > somewhat similra topics (e.g. 7-bit ASCII/UTF-8/ISO-8859 guidance)
> > fitting into style.9, but I'm not sure this one does.
>
> I think the committers guide, which needs a revamp.  That
> should also cover the 7-bit/...

Probably, yes. That said, I'm very much in favour of having the
documentation in the tree itself, for those topics pertaining to the
software in that tree (e.g. style(9), ports(7), development(7),
arch(7)).