From owner-svn-src-head@freebsd.org Fri Mar 15 02:39:20 2019 Return-Path: Delivered-To: svn-src-head@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 D793F15389AE; Fri, 15 Mar 2019 02:39:20 +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 342578274B; Fri, 15 Mar 2019 02:39:20 +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 x2F2dHJg028043; Thu, 14 Mar 2019 19:39:17 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x2F2dH9m028042; Thu, 14 Mar 2019 19:39:17 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201903150239.x2F2dH9m028042@gndrsh.dnsmgr.net> Subject: Re: svn commit: r345138 - head/share/man/man9 In-Reply-To: To: Ed Maste Date: Thu, 14 Mar 2019 19:39:17 -0700 (PDT) CC: "Rodney W. Grimes" , src-committers , svn-src-all , svn-src-head 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: 342578274B X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.949,0] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 02:39:21 -0000 > On Thu, 14 Mar 2019 at 22:10, Rodney W. Grimes > 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@freebsd.org