Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Feb 2020 16:09:09 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
Cc:        Warner Losh <imp@freebsd.org>, 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:  <CANCZdfpDPdpj5q5zDSDb1pD-wV5=SAg722jraDAEPVCXGKt8rw@mail.gmail.com>
In-Reply-To: <CANCZdfqx-m5Ya%2BxJHZrg8BU1wsk089r2EZDtaRTvDKRVaTwQhg@mail.gmail.com>
References:  <202002261855.01QIt9Ip040234@repo.freebsd.org> <CC5B2B21-0453-4AFE-A187-0029CE51D264@lists.zabbadoz.net> <CANCZdfqx-m5Ya%2BxJHZrg8BU1wsk089r2EZDtaRTvDKRVaTwQhg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 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
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpDPdpj5q5zDSDb1pD-wV5=SAg722jraDAEPVCXGKt8rw>