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

[Pedro Giffuni]

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

Pedro.