From nobody Tue Aug 16 14:51:58 2022 X-Original-To: dev-commits-src-main@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 4M6Yyf5Fgcz4ZJZQ for ; Tue, 16 Aug 2022 14:52:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 4M6Yyf4tTnz3LCP for ; Tue, 16 Aug 2022 14:52:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe34.google.com with SMTP id 67so10373448vsv.2 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=ca4cjv8snNRVBHtn+WJuYTpb43GR2rTXxLvmuQaTph6B1MC4Tq8gY7aRvkqX2Uc73j mxq68vLzna1dfWe31q9rbn6FpomKvB9O/Z5bzxAMuTu1N2M4ph96fhZkIlKiTZcwtOTt zeNyT3eiJVdA1OEiEHG8Sua0rDsAGzAa54EooaUewbnsPRu+Aue5nYVxawd7rAHI5wgp ZF+4UZHdONBu3ug+ztkoOJubEHhhvFwH89M8afjSw2TqfWG/LCxeceP5ZmnmcT0gZy8V hzQvg98NgbwatS7Nwy71fNjIVLE8jNJn9r6w5TXAa9dzYtFllpopwAm7hE6WpjpzKDzw WUxA== X-Gm-Message-State: ACgBeo00Vw48eGykG5UVuYGC+gjLP1upUF+vrXuG/9VUtA8BgMy9rArv vf5R8pQSISRd+y8NWilIcQ5Ml3ldXtRv8+4GgPM09A== 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 the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@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: 4M6Yyf4tTnz3LCP 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--