Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

On Thu, Jul 16, 2015 at 09:47:20AM -0400, Steven Rostedt wrote:

> Well, then to each their own. I prefer the content free ping, because in
> my mail client (claws), it brings the original patch up to the front
> (my threading is to sort by latest email in the thread). A simple ping
> will move their patch ahead of other patches that may have been sent
> later, but are still in the abyss.

Interesting, not noticed a mail client with that sorting scheme before.

> A resend will just be a duplicate in my inbox and it will confuse me
> about why I have more than one of the same patch.

That happens often enough anyway due to people sending new versions in
response to other review comments or similar so I find I need to cope
with discarding old copies of things anyway.

> > Not me, they tend to just annoy me for the reasons above.  Resends are
> > useful but just straight up pings not so much.

> Then a simple reply to that content-free ping to tell the author what
> you prefer. In fact, that's what I do when they ask me about it. I
> sometimes even try to send a reply when I get the original patch
> (privately to the author from my phone) that tells them to ping me in a
> week if they don't hear back from me.

That's what I do (or just ignore them if I already have the patch) but
it does get rather repetitive and adds to the mail volume which is part
of the problem.

The basic reason I advise people to resend is that if a maintainer has a
resend in their inbox they should have everything they need to handle
the patch then and there, there are fewer things that can go wrong with
that than with a content free ping.

> > I'd say a couple of weeks is a better lower limit than a single week
> > unless it's a very serious bugfix, a week could easily be a holiday or
> > whatever and larger patches or patch serieses do take time to review.

> The time length varies from person to person. Just let the author
> know what you prefer. From developers I've talked to (including
> myself), a week seems to be the norm to wait. Anything less is an
> annoyance.

Less than a week is of course far too fast, it's a good way to get
ignored.  On the other hand a week definitely does seem to too fast to
be telling people to use as a starting point, my own experience
submitting patches and watching other people submitting patches is that
a week is definitely not an unusual time to have to wait for non-urgent
things to get handled, I only tend to start worrying that things
might've been missed after a couple of weeks.

> One of the issues with newcomers coming to development of the Linux
> kernel, is that every maintainer is different. We should be trying
> harder to let people know what we prefer. Every maintainer expects
> something different, but it's up to the maintainer to explicitly let
> others know what they want. You can't expect everyone to read your
> mind.

I basically agree with that, what I'm saying on the response time is
that I don't think you're setting realistic baselines for people.  A
week is just not what's actually happening in large parts of the kernel.
There are some people I'd expect to respond within a week in the normal
course of affairs but there are more where I wouldn't worry about it and
even the more responsive people are often slower on larger changes like
new driver submissions.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]