[Question] patch posting process

[Question] patch posting process

[Vadim Lomovtsev]

Hi all,

I bring my Apologise for wasting your time, but ..

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 ?

WBR,
Vadim

Re: [Question] patch posting process

[Willy Tarreau]

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

Re: [Question] patch posting process

[Vadim Lomovtsev]

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