Re: git: 402dbdd98acc - main - Adjust function definition in arm's mv_common.c to avoid clang 15 warning
- Reply: John Baldwin : "Re: git: 402dbdd98acc - main - Adjust function definition in arm's mv_common.c to avoid clang 15 warning"
- In reply to: Cy Schubert : "Re: git: 402dbdd98acc - main - Adjust function definition in arm's mv_common.c to avoid clang 15 warning"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 16 Aug 2022 14:51:58 UTC
On Tue, Aug 16, 2022, 8:00 AM Cy Schubert <Cy.Schubert@cschubert.com> wrote: > In message <YvuD7+oK6RZ/DLzH@FreeBSD.org>, Alexey Dokuchaev writes: > > On Tue, Aug 16, 2022 at 12:10:04PM +0200, Dimitry Andric wrote: > > > ... > > > But I think it is better to have the definitions matching the > > > declarations exactly. We should sweep through the whole tree and get > > > rid of all K&R functions too. I believe Warner wanted to attempt that. > > > > I won't comment on the technical side of things, but seeing this plethora > > of identical commits is not just annoying, but pessimizes blaming as > well. > > Why can't it all be done in more coarse pieces, if not one commit? > > Agreed. > I'd prefer one burst. Cherry picking large commit that have conflicts is a real pain. Especially since the pain is different for 12 and 13. Especially since things get MFCd at different rates by different people. As someone who has had to sort that out multiple times, I know I've spent quite a bit more time unwinding one larger commit that was partially merged before I got there. It was terrible. It creates a lot of extra work for the mergers. Think boot loader that takes a while to settle before a lot of changes are mfc'd due to its huge number of combinatorics (hundreds of boot combinations) which take a while to have enough testing to know we've mitigated the risk as best we can, not all by me or even all in src/stand. With lots of commits, the lists are long but easily automated with any conflicts being quick and fast to resolve. Larger commits are bigger efforts to resolve making it harder to provide good support to old branches. And that's already hard enough. Also with one burst, it's just a range delete in my email client once. Warner > > -- > Cheers, > Cy Schubert <Cy.Schubert@cschubert.com> > FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org > NTP: <cy@nwtime.org> Web: https://nwtime.org > > e**(i*pi)+1=0 > > >