From owner-svn-src-all@freebsd.org Wed Feb 26 23:09:22 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D46E8249DCB for ; Wed, 26 Feb 2020 23:09:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48SWhd5TjMz49LY for ; Wed, 26 Feb 2020 23:09:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82e.google.com with SMTP id g21so875140qtq.10 for ; Wed, 26 Feb 2020 15:09:21 -0800 (PST) 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=/cjkW0WPkrMPfdnRXH+HTNuIQQOflEnJKhBDMRdmTRk=; b=wjwGO5wGSv6FOuyq5HcsYYKYkgyhE1eS0D2pWXhERPotBiSx7KGAX5l+5jxsWgsnwB YCD5NF7AmTM5QDPH89T2+NsMeAQUwKrDfeAme+ELJs0wHulGLcTxD9hEpY61up5D0pM9 E5QGjmxtN3tUMjS1lDQ04fBmh8RkfqNhuEVqeumTVf9Dbxm1f+5fmd58GdR3ITRZ70k7 bJNUjGK1237845cR+1HIafvNl3YX4nVqLU/ikDGTi41SSGIzgyttlkCrtUJdNtJ20U7N k87viu7qRzxN+FUlKFJDQ0CDSIJPVlFIJwOALUOtZZ1emD3/3HbjoWM2IbMPGjriJLrL n/wQ== 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=/cjkW0WPkrMPfdnRXH+HTNuIQQOflEnJKhBDMRdmTRk=; b=hAOoBIE9yb4HRU2q8+nphudWlu4YfGDMKM0mhwB0WcV53fd4F7w1Jqgrb4aOyOAyye eb7QdCsydsG9L3jb5gPneKBBWvWYBiv3E4B+igbFIk7nOIVuFpL13DdwQojKWU8S6Qh2 UFrjiVHorFasOchKcXWH3oE6Ib1xGBHHhls+LE+JZiJ/03tPb8vjjOatbchTWgQfBxAF /tz/s9nEnY3XFYFg/Mzstbe/zFbBFS4L/wYV983Z9EKP0tYYZAnGz/y5ANion/g7ryoe 2WbvHDdPE3oehZjYZmOj0mRzokg/wMM0AIMG3BW4AUbLORCKG1oRGfoodVYfTWo2B8t3 Qy4g== X-Gm-Message-State: APjAAAVpHf3ci5kWuidqub5etmX+RH3ZT/bAli3FQdsT4BGuwB2IWmIM PVJScso8zdYCTsbfVtAvDZCI0RpLOKuv1kayzneS3ilP X-Google-Smtp-Source: APXvYqwlWQm9cBXvqKjyBx1GMb6VBIsCPXArYO+BsPdj8CZUBmoO+hvB19G3hur+a5FR/OZTFfvD/NxLa3YKpx3dCXI= X-Received: by 2002:aed:3e6d:: with SMTP id m42mr1411876qtf.187.1582758560300; Wed, 26 Feb 2020 15:09:20 -0800 (PST) MIME-Version: 1.0 References: <202002261855.01QIt9Ip040234@repo.freebsd.org> In-Reply-To: From: Warner Losh Date: Wed, 26 Feb 2020 16:09:09 -0700 Message-ID: Subject: Re: svn commit: r358348 - in head/lib/libc: . gdtoa gen sparc64 sparc64/fpu sparc64/gen sparc64/sys sys To: "Bjoern A. Zeeb" Cc: Warner Losh , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 48SWhd5TjMz49LY X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=wjwGO5wG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::82e) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[e.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.57)[ip: (-9.23), ipnet: 2607:f8b0::/32(-1.88), asn: 15169(-1.67), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 26 Feb 2020 23:09:22 -0000 On Wed, Feb 26, 2020 at 3:47 PM Warner Losh wrote: > > > On Wed, Feb 26, 2020 at 12:10 PM Bjoern A. Zeeb < > bzeeb-lists@lists.zabbadoz.net> wrote: > >> On 26 Feb 2020, at 18:55, Warner Losh wrote: >> >> > Author: imp >> > Date: Wed Feb 26 18:55:09 2020 >> > New Revision: 358348 >> > URL: https://svnweb.freebsd.org/changeset/base/358348 >> > >> > Log: >> > Remove sparc64 specific parts of libc. >> >> I have a silly question for which it=E2=80=99s long been too late, but f= or the >> next time .. why do we need a gazillion of commits to remove sparc64 >> rather than 1 =E2=80=9Catomic=E2=80=9D one (or maybe 2 in case the one m= issed a bit) >> to remove it all (which would also allow other people to bring it back >> into private trees a lot more easily compared to tracking changes over >> weeks)? >> > > One atomic commit is harder and more work for me. > > It's hard to get all the details right before pushing it. It's hard to > develop it as other things in the tree change things which leads to more > conflicts. It can be hard to MFC around (though these changes won't be > MFC'd having too large a commit around them may generate more conflicts > when those things are MFC'd). So I optimized for my convenience, not othe= rs > wishing to import it into their trees. But I'd contend that the delta as > far as bringing back as 10 commits isn't onerous for such a niche demand. > Also, if I screw something up, it's easier to back out smaller commits should that be necessary. Backing out huge commits that remove lots of things and then reapplying them is tedious and error-prone. Doing it a little at a time also allows me to make sure that all the CI stuff works before moving on to the next step. > We don't remove entire architectures often, and we usually do because the= y > work poorly at best. > > Warner >