From: Willy Tarreau <w@1wt.eu>
To: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
Cc: linux-kernel@vger.kernel.org, vadim.lomovtsev@cavium.com
Subject: Re: [Question] patch posting process
Date: Fri, 6 Apr 2018 21:21:46 +0200 [thread overview]
Message-ID: <20180406192146.GA384@1wt.eu> (raw)
In-Reply-To: <20180406182916.GA15772@localhost.localdomain>
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
next prev parent reply other threads:[~2018-04-06 19:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-06 18:29 [Question] patch posting process Vadim Lomovtsev
2018-04-06 19:21 ` Willy Tarreau [this message]
2018-04-06 20:00 ` Vadim Lomovtsev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180406192146.GA384@1wt.eu \
--to=w@1wt.eu \
--cc=Vadim.Lomovtsev@caviumnetworks.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vadim.lomovtsev@cavium.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox