From owner-svn-src-head@freebsd.org Thu Mar 14 23:36:19 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 2530015339A8 for ; Thu, 14 Mar 2019 23:36:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 BA52173AAC for ; Thu, 14 Mar 2019 23:36:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id k2so8228741qtm.1 for ; Thu, 14 Mar 2019 16:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X0Fo4l0JJKy4J3hU4TDhR75ISizDYLfrLeyWdB34qQA=; b=K1u0cYNc08bvPyPly03kCn+LR6V8pqPvP4GwZsbH/lailcr3M5zf8X8sLW9KqbcZLW K8isZP10TYALh4zzAk/XqHmzioKDvBQ2QNXuc6s66OLFWFr849V94UjdgH0tEp/raiSZ V7qmT9B56YKgk8Z8ngP0TzRTll3Oa7mIqjp5MhKEgjJhunrJMx+wuCtlin0tyvVHtHPe 9+CvExiFHAJcE0G5Z6zreqC7zGzA2IOE7OE/pKYqm1NRsXkjBXfL0GWyM/B5IieixZ/s jeuoPnRcWvSGwSwu3z4xT1FpSGgDQB8OofgCL10HRRGMUrKQdbu1FyPezPdkuik4aEsv IZdQ== 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=X0Fo4l0JJKy4J3hU4TDhR75ISizDYLfrLeyWdB34qQA=; b=f0RIwEDz5KFzKOW0qypkwE1eoNgwBzKFrY4UKngH7gUq+HF63fdsit11xJ0zTAF5RZ A0np/LKGOh1zhmhs69BkqrKpoaR/kZZzNAwPwJkOXde95F2CCMJjapEu2G6H8Gtr3yiY cX+P27ecIvyYs5Dnje5QXl5R/grUrY5QkEZdNXoVXi7Z64ZMTwaN8QNa1y9BPAlPHpvD Ac9c1TmqLAFfbwThVmL6BMuko6mjWdIla3B5NivsfsTmSGsY+0sUhzpyiK0KZCB2vsjc 9w2oxjgYwFx2oxaFNuJ4qK1s/+fZ76bXDHHUURSpEr10arRDarbq1DMDm6/d+R/s1Yma uvZQ== X-Gm-Message-State: APjAAAVF4XLso4OBcvDJvtGqfwhCiOVoYxHqfNu3bmkTTJix69iF2eJS IxUdGwJO5j2eMEH6TQCYkijWSOe2jy3NcQjBAwVlYQ== X-Google-Smtp-Source: APXvYqypJzWjF2mIVAheqD4ymhSnB2P3TmC7YYsbBjmVcX/g49aXLnrUVkCnK4MyNHI9uILxHIrWbT1U1IwHd8lWfJE= X-Received: by 2002:ac8:1aec:: with SMTP id h41mr508303qtk.345.1552606577869; Thu, 14 Mar 2019 16:36:17 -0700 (PDT) MIME-Version: 1.0 References: <201903141709.x2EH97e7090941@repo.freebsd.org> <201903141855.x2EIt2ih026401@gndrsh.dnsmgr.net> In-Reply-To: From: Warner Losh Date: Thu, 14 Mar 2019 17:36:06 -0600 Message-ID: Subject: Re: svn commit: r345138 - head/share/man/man9 To: Ed Maste Cc: "Rodney W. Grimes" , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: BA52173AAC 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_SHORT(-0.95)[-0.955,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 14 Mar 2019 23:36:19 -0000 On Thu, Mar 14, 2019 at 3:43 PM Ed Maste wrote: > 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. > CVS had issues with them. sup had issues with them (remember sup?). CTM originally didn't cope but does now (not sure when that changed). By the time I joined in 95 or so, it was already part of the oral tradition. It was all over the mailing lists and just something you were expected to know. I even have a recollection of people screwing up and there being CVS repo surgery to remove the binary version and bring forward only the .uu versions. But that was 20ish years ago, so I'm not certain. > > 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. > It no longer applies. svn copes well, git copes well, perforce coped well (though not too relevant these days). IIRC, there used to be something about it in the CVS section of one of the handbook chapters, but all that stuff was removed a long time ago and may be hard to find today. > 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). > Yes. Bringing a file off a vendor branch was generally greeted with much gnashing of teeth and much bile. And for good reason: the person taking it off the vendor branch was trivial, but it caused real and lasting conflicts for every single new import after that. The pain was real, and borne by the maintainer, not by the taker-off-the-brancher. > > 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. > This feels more like committer guide material, not style.9 to me. The committer guide is showing its age and collection of random detritus that we need to reorganize and update. This is one of the many issues. > > 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. > I'd convert them when there's some other reason to handle them. I'm not swayed by the churn argument, but more because there's little gain here, at the moment, and it would take someone's time. But if someone takes the time, I wouldn't stand in the way. Warner