From owner-svn-src-head@freebsd.org Thu Feb 27 05:06:07 2020 Return-Path: Delivered-To: svn-src-head@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 62C4F25531B for ; Thu, 27 Feb 2020 05:06:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) (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 48SgcG2RVvz45cw for ; Thu, 27 Feb 2020 05:06:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf44.google.com with SMTP id by15so956668qvb.11 for ; Wed, 26 Feb 2020 21:06:06 -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=qWwR6JdfqDtaiL7hNMY019muq7h5FkRJsp2YJTMsyJs=; b=Dtg3Gw6z512Vzu4k+/snuzY+5UoMqYCcwCbNh3XZsLJ8qdUWc8PD1YeprjW7mqwsGf S8B8QXOl1RNM7rfFvWiSspPuj7CWORNN0+h15uXQn9WH17OOaSEbMzoViw/615SNXxjx mxgL0lM5c5slxycD7NlYgC4AQ/sNCjpuJikAEwPlB4Dmhl1N82V6kS/k+F6h1li1yT1X TTUOINm5pHTNgI9LW4r2tuTSL88QGm/YAAaAF2vR6A6Gpat8rGPOvlXtzYABTJ0VZVpi MTSZGryn1EcSX8iDjC+Z1ETpJHH4t3NUJooVUverHY1DqwWKr9iV65Viun1h8n+62SKF d4fg== 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=qWwR6JdfqDtaiL7hNMY019muq7h5FkRJsp2YJTMsyJs=; b=ggH191jZ0ucvZH/nZ/ErfpxioMzgAOZMoSgWFvg8OgO/MEbv0z6WNe1ruVONAzlgjc IrsPnkhP/VWktwRX/4n3YI32XmISJ/YDyh+QcNGBbIdPYPQYDIFApjEd6e7xSFkoLCTG IwZ1bFSga8CYA/7RxTUmFZqmM0jt47pDzbLgmagP96WoZg6JFvl70/MftEgScrarz93f 8PXgU7sh50wNcn38xB5lJvXMrCPWJWhfG9iLxG8JjjVX8Uwb9VxmuTti5WWV6s4ZsVln 6hseqp7Z2ii9GvYqiINwj/84GIxB+eqxLV76HjQGnugKCdn2jxHMFyV1GFnx1PfVG5fK rnuQ== X-Gm-Message-State: APjAAAWvoCh6cKQ13OHFLd+cjvvTHVoLxoOG/s2WWz/yq6C/y0KSXUez uoii5HUil6QCO5FPntUOB6E06rkIf4OMAQoLsBCA2g== X-Google-Smtp-Source: APXvYqweKHOU7HjdFCuHyMFcRcxTANEMxCPgtVNYnJZMBfKMHctd+MgKnfNmdTK3tvtyIkU0D5u6gakYY7viN/ywwlY= X-Received: by 2002:a0c:ee91:: with SMTP id u17mr2723736qvr.22.1582779965319; Wed, 26 Feb 2020 21:06:05 -0800 (PST) MIME-Version: 1.0 References: <202002261855.01QIt9Ip040234@repo.freebsd.org> In-Reply-To: From: Warner Losh Date: Wed, 26 Feb 2020 22:05:53 -0700 Message-ID: Subject: Re: svn commit: r358348 - in head/lib/libc: . gdtoa gen sparc64 sparc64/fpu sparc64/gen sparc64/sys sys To: Pedro Giffuni Cc: "Bjoern A. Zeeb" , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 48SgcG2RVvz45cw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Dtg3Gw6z; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::f44) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.62 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@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:+]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.63)[ip: (0.48), 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-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, 27 Feb 2020 05:06:07 -0000 On Wed, Feb 26, 2020, 9:36 PM Pedro Giffuni wrote: > > On 26/02/2020 18:09, Warner Losh wrote: > > > > 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 = for 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 = missed 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 oth= ers >> 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 should/could nevertheless, track the removal process in some PR, or in > the Wiki, to make life easier to whomever hero wants to resurrect the > changes (not that I see that happening) > Go for it. Since I don't see anybody doing it either, I view it as wasted work. Git log can dig this out easily enough, though. Warner >