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

["Mike Beaton" <mjsbeaton@gmail.com>]

I did ask. Thank you for the considered answer. Ack. :)

On Thu, 14 Dec 2023 at 13:25, Laszlo Ersek <lersek@redhat.com> 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]
-=-=-=-=-=-=-=-=-=-=-=-