Messages in this thread | | | Date | Fri, 6 Apr 2018 13:00:23 -0700 | From | Vadim Lomovtsev <> | Subject | Re: [Question] patch posting process |
| |
Hi Willy,
Thank you for your opinion, it's very helpful.
WBR, Vadim
On Fri, Apr 06, 2018 at 09:21:46PM +0200, Willy Tarreau wrote: > Hi Vadim, > > On Fri, Apr 06, 2018 at 11:29:16AM -0700, Vadim Lomovtsev wrote: > > Hi all, > > > > I bring my Apologise for wasting your time, but .. > > Questions about doing things right rarely are a waste of time if they save > others from having to do useless work! > > > May I ask for some clarification.. When we're speaking of 'posting patches shortly' > > does it mean to send them in next few hours ? > > Or would it be more acceptable to post one version per day > > even for very small changes in between ? > > > > Kernel posting guides says that one should wait for about a week for respond, > > but in my case I've got feedback rather quickly (thanks a lot for that!) > > and I'd assume that I can proceed with posting next version. > > > > So, what is the proper approach here - should one wait day or two > > before posting next version even if changes are very simple ? > > Generally speaking, it's better to proceed ASAP. Reviewing patches requires > some concentration and often some time to get into the context. Speaking for > myself only, when I'm reviewing patches (I reserve time to do it), I prefer > to get 3 round trips the same day than one per week and each time having to > try to recall what it was about and what I proposed. > > Also some people may only do that on spare time, week-ends or dedicated day > in the week. If you sit on their e-mail for no reason, you expose yourself > to the risk of having to wait for the next feedback. This is where the week > comes from. Another nice side effect of the week delay is that some people > send a first version for reviewing and figure by themselves that this > version is bogus, then send a fixed version. That reduces the number of > required work for reviewers. > > On the other hand, it's not nice to rush quick updates without verifying > that you properly addressed all reported points (addressed either in code > or discussion). Thus my recommendation would be that if you can iterate > one or two extra rounds the same day, that's generally much better. And > in any case if the reviewer doesn't have more time to assign to you, he > will switch to something else and you'll have to wait. Thus the good rule > could be that ideally reviewers should not needlessly be waiting for you. > > One important point however is *not* to send multiple versions of the > same series without waiting for a review. Someone might already be reading > your patchset and be pissed off by discovering he's reading outdated > code. Reserve this for the cases where you've let a huge bug slip > through. > > Just my two cents, others will very likely have other advices. > > Willy
| |