I did ask. Thank you for the considered answer. Ack. :) On Thu, 14 Dec 2023 at 13:25, Laszlo Ersek <ler...@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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-