From owner-svn-src-all@freebsd.org Thu Mar 14 21:43:20 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 642E9152F651; Thu, 14 Mar 2019 21:43:20 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04BE26EB7D; Thu, 14 Mar 2019 21:43:19 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it1-f176.google.com with SMTP id e24so7200393itl.1; Thu, 14 Mar 2019 14:43:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ja0ZGbZ3YQtJGydGkuNaOSIK8A4PvGymVeQC5qQ8JKM=; b=UPF7On08NG6UYzUNswAIrXERfYCfhj5PaQUbELZ8n17ATFBpBNBgsgyiHHK5w+wb4l HG4lDpoQwdyyXSf/bsWUzpY4nNA8VSN+sjeZK2HMQcTUSRfjItK5UNdvW5z5dqr5AfiI Es3IC4tke1Q1UUsqWQYkp+IwKZbAWQf+FwvkB9lfgezB8jpmzhjcnPEYawNP0IocuAYB 7W83HTn/pFo6Y8XlOmiTjQPaoxR9lDvV+XpWn6HZ31xus99HwFbO7SsVqg6jf/9kXMnt 4BK/txxgiICIR6b+YB5Kc+FxCFQCWyIX4A+M52l4lXzN84WzNF1uf2mLI02HewKSBTl7 tq3A== X-Gm-Message-State: APjAAAXCy3PVwj57BL1GWMb4qNzT8RC33OFakNNENgMpt9GgsBzl+u+o Nkj4ScK72uVrm2q2Awh/zUNZ/cdeLiV8PCsH3+okcA== X-Google-Smtp-Source: APXvYqz5A0+4t++drG144x9Rf/BWFAwr3/pfWcDYRY9II/ejH09wWm1hLX2pa2buMJ/N9w4dk1w4kNKc1ystZIFEKEs= X-Received: by 2002:a24:6f94:: with SMTP id x142mr423558itb.33.1552599361427; Thu, 14 Mar 2019 14:36:01 -0700 (PDT) MIME-Version: 1.0 References: <201903141709.x2EH97e7090941@repo.freebsd.org> <201903141855.x2EIt2ih026401@gndrsh.dnsmgr.net> In-Reply-To: <201903141855.x2EIt2ih026401@gndrsh.dnsmgr.net> From: Ed Maste Date: Thu, 14 Mar 2019 17:35:47 -0400 Message-ID: Subject: Re: svn commit: r345138 - head/share/man/man9 To: "Rodney W. Grimes" Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 04BE26EB7D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.94 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.945,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: Thu, 14 Mar 2019 21:43:20 -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). > 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.