svn commit: r358348 - in head/lib/libc: . gdtoa gen sparc64 sparc64/fpu sparc64/gen sparc64/sys sys

[Warner Losh]

On Wed, Feb 26, 2020, 9:36 PM Pedro Giffuni <pfg at freebsd.org> wrote:

>
> On 26/02/2020 18:09, Warner Losh wrote:
>
>
>
> On Wed, Feb 26, 2020 at 3:47 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Wed, Feb 26, 2020 at 12:10 PM Bjoern A. Zeeb <
>> bzeeb-lists at 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)
>
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

>