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

[Rodney W. Grimes]

> 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).

4. There is no easy way to show
   "changed byte at offset 0x432 from 0xef to 0xfe"

So far, that looks right.
Do we have a decent binary diff and binary patch tool?

> > > 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)).

I do not have much problem with it being multiple places,
so long as they are all cross referenced either directly
in words, or at least in markup comments so that when one
place is changed the others are too.

-- 
Rod Grimes                                                 rgrimes at freebsd.org