Date: Thu, 14 Mar 2019 17:35:47 -0400 From: Ed Maste <emaste@freebsd.org> To: "Rodney W. Grimes" <rgrimes@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r345138 - head/share/man/man9 Message-ID: <CAPyFy2CEbKMNVUJ6_mthfq3QL6tq5V0jjoZ01eX82-2kwqLFkQ@mail.gmail.com> In-Reply-To: <201903141855.x2EIt2ih026401@gndrsh.dnsmgr.net> References: <201903141709.x2EH97e7090941@repo.freebsd.org> <201903141855.x2EIt2ih026401@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes <freebsd@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). > 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. > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2CEbKMNVUJ6_mthfq3QL6tq5V0jjoZ01eX82-2kwqLFkQ>