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

[Rodney W. Grimes]

> On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes
> <freebsd at gndrsh.dnsmgr.net> wrote:
> >
> > We should of documented what the decision process and criteria was
> > that lead to the decission to uuencode the files.
> 
> Doing some archaeology, the first instance of a uuencoded file I can
> find is r1796, "Got rid of a couple of binary files by uuencoding.  49
> more to go." There's no explanation of why the change was made.
> Evidence suggests that in 1994 it was just accepted as impossible or
> not permitted to have binary files in the tree, but this has not been
> the case for quite some time.
> 
> > Thus we could easily revist that criteria, see how much of it no
> > longer applies, possible add counter criteria, and change this
> > decision, with it documented as to why it changed.
> 
> With none of this documented anywhere I'm going to rely on oral
> history from you, phk, or other FreeBSD committers active in the mid
> 90s to provide guidance on what we can revisit and what to check if it
> no longer applies.
> 
> 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.

> > As is this is just another semi documented project guideline change,
> > I believe there are more than just the firmware files that this
> > change needs noted on.
> 
> 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/...

> > We should also note that if they are already in uuencode state
> > to leave them in uuencode state, or do we intened to convert
> > them on next commit, or ???
> 
> Good point, converting existing .uu files to binary is just
> unnecessary churn and is not recommended. If someone is going to make
> a change it can be done with the next update.

Covered this in my reply to Warners reply.  I think we also need to
look at how this might affect vendor imported stuff, is there some if
it that was .uu'ed before import?

-- 
Rod Grimes                                                 rgrimes at freebsd.org