From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 554B17803CF for ; Thu, 14 Dec 2023 13:25:15 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=hht4zpwIXZU2yc13Lr41BP2Nc7HrlVkmYPzhA1nIB3I=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1702560314; v=1; b=tB39rmGLfXdVJQOW4p79l+br4Xyiue4Uyy3g8zplaC0YPaYUxnhKlqBSck4TjCOp76HcQv/U Ijr3YEnkx4f+Q/A9I6PLipGfC2n/6PYvc4ZBAWOIzAouxHXJ/D3uLX4xgJjMhX2G+LcPMFb4mbc +ftm8/mAGTXpvlfh68+p3gyk= X-Received: by 127.0.0.2 with SMTP id xuMcYY7687511xhnCqQE3ZeI; Thu, 14 Dec 2023 05:25:14 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.21861.1702560313186245878 for ; Thu, 14 Dec 2023 05:25:13 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-418-FbsF07YnOGa3MG8Zxq7hmQ-1; Thu, 14 Dec 2023 08:25:09 -0500 X-MC-Unique: FbsF07YnOGa3MG8Zxq7hmQ-1 X-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D90343C025B8; Thu, 14 Dec 2023 13:25:08 +0000 (UTC) X-Received: from [10.39.193.43] (unknown [10.39.193.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 521D940C6EBA; Thu, 14 Dec 2023 13:25:08 +0000 (UTC) Message-ID: Date: Thu, 14 Dec 2023 14:25:07 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH V6] DebugLib: Update DEBUG macro used when MDEPKG_NDEBUG is defined To: devel@edk2.groups.io, mjsbeaton@gmail.com, Ard Biesheuvel References: <20231214091146.5034-1-mjsbeaton@gmail.com> <2894.1702545170551635627@groups.io> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: ntyvShfXKOew3HneYlwVyvi6x7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=tB39rmGL; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 12/14/23 10:33, Mike Beaton wrote: >> Please stop sending patches. >=20 > I believe this version is a clear improvement, with motivation. > (Certainly, it was meant as such!) >=20 > How am I meant to send improvements or updates in this email-based workfl= ow? By pacing yourself. Posting two versions of the same patch set on the same day is usually the highest tolerable posting frequency. Many would say 1 version/day is the limit (unless there is a pressing security issue or CI failure etc). Basically the request is for the submitter to think more, let their latest version soak for longer locally, before posting it. BTW I don't think this is specific to email, the same issue exists on any git forge, except perhaps to a lesser extent. Both channels are asynchronous, so if you repost or force-push too quickly, you don't give reviewers a chance to finish (or even *start*) the last version's review. Well, interrupting them may actually be your intent, but that's just not how async communication works. Once you posted it, it's out there, and it's going to take up some consumer cycles for sure, either way, regardless of what you do later. You can't recall it, you're not in the same office at the same time. github *seems* to mitigate this, because the old version more or less just disappears. But that's actually a bug of git forges, not a feature. Patch posting history should never be forgotten. Mailing lists get this right, but that makes misbehavior (=3D too frequent posting) more damaging, as the total traffic the receiver will have to wade through will be higher. In short: don't experiment, don't thrash. Make every version of your patch set *count*. Give yourself more time to think about your latest version *in the background*, before posting it. If you sleep over it, the next day you might get a new idea, regardless of whether you posted or didn't yet post that version. So, as long as it hasn't settled, don't post it. If you realize an issue after posting the latest version, respond -- just like a reviewer would -- to the problematic patch email, pointing out the error; but *don't* post a new version just yet (i.e., don't create a new version / thread on the list). Your attempt to "recall" the problematic version is bound to fail. In short, s/TCP_NODELAY/TCP_CORK/. Sorry about the sermon -- you asked. :) Laszlo -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112526): https://edk2.groups.io/g/devel/message/112526 Mute This Topic: https://groups.io/mt/103166935/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-