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 17214D8119E for ; Thu, 14 Dec 2023 13:29:13 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=HrSSGoL4eQ94kdfFa78iPZ4UmKAWzLqdHAGLr0CgiTM=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1702560552; v=1; b=fqO90GzobMF/HVwT0cII8P2V4hZ+uEYZJWQ/xauCKDIj135OePze/2dM+hXDhDke3PYFW9T7 DAYpMdx3i9fGaTXlOxh5SQcBJBFUcxG4dj80SwCgFZByVKTYdDoc5PQFUwduYh2GfpEv2Tr2e1G bM7SuNYipQT6L4jXmgXMg/tU= X-Received: by 127.0.0.2 with SMTP id T9cRYY7687511xn7m2qc9zJj; Thu, 14 Dec 2023 05:29:12 -0800 X-Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by mx.groups.io with SMTP id smtpd.web11.21913.1702560551988577811 for ; Thu, 14 Dec 2023 05:29:12 -0800 X-Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-40c317723a8so72057695e9.3 for ; Thu, 14 Dec 2023 05:29:11 -0800 (PST) X-Gm-Message-State: 5HtTG6ogHywjXHxQm5OAcMF7x7686176AA= X-Google-Smtp-Source: AGHT+IGhAX8EHHFS6MiwHTjDjnwPKKBA9acFv+RoAvQVl9GSpsN6dKFEd14QNRGVErGL1bGVN5sbyvBOyLD4MI4926g= X-Received: by 2002:a05:600c:c0d:b0:40c:3e82:4d96 with SMTP id fm13-20020a05600c0c0d00b0040c3e824d96mr4384624wmb.24.1702560550013; Thu, 14 Dec 2023 05:29:10 -0800 (PST) MIME-Version: 1.0 References: <20231214091146.5034-1-mjsbeaton@gmail.com> <2894.1702545170551635627@groups.io> In-Reply-To: From: "Mike Beaton" Date: Thu, 14 Dec 2023 13:28:58 +0000 Message-ID: Subject: Re: [edk2-devel] [PATCH V6] DebugLib: Update DEBUG macro used when MDEPKG_NDEBUG is defined To: Laszlo Ersek Cc: devel@edk2.groups.io, Ard Biesheuvel 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,mjsbeaton@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=fqO90Gzo; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none) I did ask. Thank you for the considered answer. Ack. :) On Thu, 14 Dec 2023 at 13:25, Laszlo Ersek wrote: > > On 12/14/23 10:33, Mike Beaton wrote: > >> Please stop sending patches. > > > > I believe this version is a clear improvement, with motivation. > > (Certainly, it was meant as such!) > > > > How am I meant to send improvements or updates in this email-based workflow? > > 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 (= 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 > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112527): https://edk2.groups.io/g/devel/message/112527 Mute This Topic: https://groups.io/mt/103166935/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-