Date: Wed, 26 Feb 2020 22:05:53 -0700 From: Warner Losh <imp@bsdimp.com> To: Pedro Giffuni <pfg@freebsd.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r358348 - in head/lib/libc: . gdtoa gen sparc64 sparc64/fpu sparc64/gen sparc64/sys sys Message-ID: <CANCZdfpJ81dgeBAbxPU8ed_Oqy2EpeYU5Utd2P0i89fgENqMsg@mail.gmail.com> In-Reply-To: <bac52803-b498-d88c-24be-a84a46fd23bf@FreeBSD.org> References: <202002261855.01QIt9Ip040234@repo.freebsd.org> <CC5B2B21-0453-4AFE-A187-0029CE51D264@lists.zabbadoz.net> <CANCZdfqx-m5Ya%2BxJHZrg8BU1wsk089r2EZDtaRTvDKRVaTwQhg@mail.gmail.com> <CANCZdfpDPdpj5q5zDSDb1pD-wV5=SAg722jraDAEPVCXGKt8rw@mail.gmail.com> <bac52803-b498-d88c-24be-a84a46fd23bf@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 26, 2020, 9:36 PM Pedro Giffuni <pfg@freebsd.org> wrote: > > On 26/02/2020 18:09, Warner Losh wrote: > > > > On Wed, Feb 26, 2020 at 3:47 PM Warner Losh <imp@bsdimp.com> 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpJ81dgeBAbxPU8ed_Oqy2EpeYU5Utd2P0i89fgENqMsg>