From owner-svn-src-all@freebsd.org Fri Mar 15 02:10:14 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82B681537812; Fri, 15 Mar 2019 02:10:14 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE58280C87; Fri, 15 Mar 2019 02:10:13 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x2F2ABJY027878; Thu, 14 Mar 2019 19:10:11 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2F2ABwZ027877; Thu, 14 Mar 2019 19:10:11 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201903150210.x2F2ABwZ027877@gndrsh.dnsmgr.net> Subject: Re: svn commit: r345138 - head/share/man/man9 In-Reply-To: To: Ed Maste Date: Thu, 14 Mar 2019 19:10:11 -0700 (PDT) CC: "Rodney W. Grimes" , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: CE58280C87 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.949,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 02:10:14 -0000 > On Thu, 14 Mar 2019 at 14:55, Rodney W. Grimes > 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@freebsd.org