From nobody Tue Aug 16 14:51:58 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M6Yyf6D9Mz4ZJPf for ; Tue, 16 Aug 2022 14:52:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M6Yyf53VGz3L0N for ; Tue, 16 Aug 2022 14:52:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe33.google.com with SMTP id b124so10346018vsc.9 for ; Tue, 16 Aug 2022 07:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=RPolc+br+Y/ugOcHmRYOMcvOc3CGEaqSx7KUktn5jok=; b=OYgRlyUgVkmw3GvgxGC4pnCToASEBrjayemtVoWeMmge3bq4WD4kcJttYPEXFEZuPI rAL4KK3FAfMRpHdMUDNWzQaH6GSuOLqywRDfkf50/RDcMrlJN+34Q7VYilUg/3qn9jHu vWUfsmKqolQ31nDTFFWuMFtlYBGEnd0lBdi9uIKma3+39dyQ/3vXOddy+w52kvZ+xSgT 1d9OerGFwVDNR60fP97VYbq4xCmGxmwyVVNaJRqsBPVVN/QRPypnoO3sNSEZ5PXrJJVE tGmK6Erkiw0VifVU5SrZQHJ+cVgTEK4o4qv8bW1lKYMZzn4GqdbISO/sy5kFdqHOPrTl FSgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=RPolc+br+Y/ugOcHmRYOMcvOc3CGEaqSx7KUktn5jok=; b=SVLEscjkF9ujf9vu8+bNKinG3WrKDlQXz/a9VG6Je4FtKYQfC+eDy6dIeaDWqF8oF8 x3co7Pwb7Of+79jrlLr2UwqH0ts0xyXx4EKp5xx3XUCafzLJr2oSnUCAo32kL9eWNBEq WgHAmhQVqsXBkk92bbPU3r+kSv7AagEWryThIRFQIKIcXMe04v/5xDB5tLIeMtoJUMRC osmsVtHJLNFcxU1Cr1WAGT3uOiqw+2Pd2G530Yi8XNe+xEjL0Ek49Pna8QCQpciTtlUB QJKfbyKH/TdWaLnQ7zDpWlE3xkP4019f89ypbViJbWgEP+dEV/t7YaJV/3Ra6Gq5RaVz 38DQ== X-Gm-Message-State: ACgBeo3650BejmIzGoI3aUEybNHlT2ANmcW0t01XoI1bO+lJISDL48RC esff8ZSPyY02onHcaGHGPHmL80lLf2sTHPwHbPV/dg== X-Google-Smtp-Source: AA6agR5JQE2Oe+SzXjMGwD11v8qyuu4mIqUVRzeQ3Lb821hn/3L9vqnS4B0A3Vn8R7qpf27vX5ipj1w7UzNdhETkFF4= X-Received: by 2002:a67:ac45:0:b0:388:a1ff:7e89 with SMTP id n5-20020a67ac45000000b00388a1ff7e89mr9043207vsh.42.1660661529932; Tue, 16 Aug 2022 07:52:09 -0700 (PDT) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202208151849.27FInHmh027652@gitrepo.freebsd.org> <20220816140000.365C5150@slippy.cwsent.com> In-Reply-To: <20220816140000.365C5150@slippy.cwsent.com> From: Warner Losh Date: Tue, 16 Aug 2022 08:51:58 -0600 Message-ID: Subject: Re: git: 402dbdd98acc - main - Adjust function definition in arm's mv_common.c to avoid clang 15 warning To: Cy Schubert Cc: Alexey Dokuchaev , Dimitry Andric , Jessica Clarke , Konstantin Belousov , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000958a4f05e65ce46d" X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Rspamd-Queue-Id: 4M6Yyf53VGz3L0N X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000958a4f05e65ce46d Content-Type: text/plain; charset="UTF-8" On Tue, Aug 16, 2022, 8:00 AM Cy Schubert wrote: > In message , 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 > FreeBSD UNIX: Web: http://www.FreeBSD.org > NTP: Web: https://nwtime.org > > e**(i*pi)+1=0 > > > --000000000000958a4f05e65ce46d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 16, 2022, 8:00 AM Cy Schubert <= Cy.Schubert@cschubert.com> wrote:
In message <YvuD7+oK6RZ/DLzH@FreeBSD.org>, Alexey Dokuchaev wri= tes:
> 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 atte= mpt that.
>
> I won't comment on the technical side of things, but seeing this p= lethora
> of identical commits is not just annoying, but pessimizes blaming as w= ell.
> 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 conf= licts 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. A= s someone who has had to sort that out multiple times, I know I've spen= t quite a bit more time unwinding one larger commit that was partially merg= ed 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= 9;ve mitigated the risk as best we can, not all by me or even all in src/st= and. With lots of commits, the lists are long but easily automated with any= conflicts being quick and fast to resolve. Larger commits are bigger effor= ts 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 cli= ent once.

Warner

--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 http://www.FreeBSD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>= ;=C2=A0 =C2=A0 Web:=C2=A0 https://nwtime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e**(i*pi)+1=3D0


--000000000000958a4f05e65ce46d--