Re: [edk2-devel] [PATCH V6] DebugLib: Update DEBUG macro used when MDEPKG_NDEBUG is defined

["Laszlo Ersek" <lersek@redhat.com>]

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 (#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/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-