Date: Wed, 26 Feb 2020 23:36:32 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Warner Losh <imp@bsdimp.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: 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: <bac52803-b498-d88c-24be-a84a46fd23bf@FreeBSD.org> In-Reply-To: <CANCZdfpDPdpj5q5zDSDb1pD-wV5=SAg722jraDAEPVCXGKt8rw@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26/02/2020 18:09, Warner Losh wrote: > > > On Wed, Feb 26, 2020 at 3:47 PM Warner Losh <imp@bsdimp.com > <mailto:imp@bsdimp.com>> wrote: > > > > On Wed, Feb 26, 2020 at 12:10 PM Bjoern A. Zeeb > <bzeeb-lists@lists.zabbadoz.net > <mailto: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’s long been too late, but > for the > next time .. why do we need a gazillion of commits to remove > sparc64 > rather than 1 “atomic” 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 others 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). Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bac52803-b498-d88c-24be-a84a46fd23bf>