All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: "Thierry Reding" <thierry.reding@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-pwm@vger.kernel.org,
	"Subbaraman Narayanamurthy" <subbaram@codeaurora.org>,
	"David Collins" <collinsd@codeaurora.org>,
	linux-kernel@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
	"Dan Carpenter" <dan.carpenter@oracle.com>,
	"Daniel Thompson" <daniel.thompson@linaro.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Joe Perches" <joe@perches.com>
Subject: Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64
Date: Thu, 21 May 2020 08:15:05 +0100	[thread overview]
Message-ID: <20200521071505.GL271301@dell> (raw)
In-Reply-To: <20200520231508.GA29437@codeaurora.org>

On Wed, 20 May 2020, Guru Das Srinagesh wrote:

> On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> > On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> > 
> > > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > > A great deal of mailing lists contain numerous protections against
> > > > things like flooding and spamming.  One of those protections is a
> > > > check for "Too many recipients to the message".  Most of the time this
> > > > simply requires moderator intervention by way of review and approval,
> > > > but this ultimately depends on the ML's configuration.
> > > > 
> > > > The first thing to ascertain is why your recipients list is so large.
> > > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > > that a little.  Contributors do not tend to care about subsequent
> > > > changes to a file.  As someone who receives a lot of patches, I tend
> > > > to get fed-up when receiving patches simply because I made a change X
> > > > years ago.  Stick to listed maintainers/reviewers in the first
> > > > instance and see how far that takes you.
> > > 
> > > Thank you for the detailed reply. I did this in the first few patchsets
> > > and then when a few patches didn't get any attention, expanded the
> > > audience thus. Still, around 50% of the patches in this series remain
> > > unreviewed by anyone.
> > 
> > This isn't a reason to add more recipients (who are likely to care
> > even less than your original group).  However it *is* a good argument
> > for including all of the specified maintainers/reviewers in on all of
> > the patches.
> > 
> > > > If your recipients list is as succinct as reasonably possible, maybe
> > > > just accept that every version isn't going to be archived by every
> > > > ML.  It's still much more useful for the correct people to have
> > > > visibility into the set than for it to be archived multiple times.
> > > 
> > > Thank you, will prune the list and remove past contributors from the
> > > Cc-list and add all parties to all patches.
> > 
> > Great.  Once you've done that, we can start to help you acquire the
> > Acks you need on your remaining patches.
> 
> Hi Lee, Thierry, Uwe,
> 
> In v14 of this patchset I've pruned the list of contributors, removed
> past contributors from the cc-list, and added all parties to all patches
> (except for the patches that are yet to reviewed, for which I've added
> what get_maintainer.pl showed me). I've also resent v14 a couple of
> times already, with around a week's time interval between resends, and
> somehow it seems like this set has lost traction.
> 
> Could you please indicate what next steps I should take to have more
> eyes on the unreviewed patches? Only 4 out of 11 patches remain
> unreviewed.

Looks like we're waiting on Thierry (again).

This has been a common theme over the past few months.

Perhaps he has changed employer/project?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-05-21  7:15 UTC|newest]

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22  2:57 [PATCH v13 00/11] Convert PWM period and duty cycle to u64 Guru Das Srinagesh
2020-04-22  2:57 ` [Intel-gfx] " Guru Das Srinagesh
2020-04-22  2:57 ` Guru Das Srinagesh
2020-04-22  2:57 ` Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 01/11] drm/i915: Use 64-bit division macro Guru Das Srinagesh
2020-04-22  2:57   ` [Intel-gfx] " Guru Das Srinagesh
2020-04-22  2:57   ` Guru Das Srinagesh
2020-04-24  6:17   ` Jani Nikula
2020-04-24  6:17     ` [Intel-gfx] " Jani Nikula
2020-04-24  6:17     ` Jani Nikula
2020-04-24  6:17     ` Jani Nikula
2020-04-24 22:17     ` Guru Das Srinagesh
2020-04-24 22:17       ` [Intel-gfx] " Guru Das Srinagesh
2020-04-24 22:17       ` Guru Das Srinagesh
2020-04-27 13:48       ` Jani Nikula
2020-04-27 13:48         ` [Intel-gfx] " Jani Nikula
2020-04-27 13:48         ` Jani Nikula
2020-04-22  2:57 ` [PATCH v13 02/11] hwmon: pwm-fan: " Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 03/11] ir-rx51: " Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 04/11] pwm: clps711x: Cast period to u32 before use as divisor Guru Das Srinagesh
2020-04-23  9:30   ` Geert Uytterhoeven
2020-04-23  9:30     ` Geert Uytterhoeven
2020-04-24 22:21     ` Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 05/11] pwm: pwm-imx-tpm: Use 64-bit division macro Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 06/11] pwm: imx27: Use 64-bit division macro and function Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 07/11] pwm: sifive: Use 64-bit division macro Guru Das Srinagesh
2020-04-22  2:57   ` Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 08/11] pwm: sun4i: Use nsecs_to_jiffies to avoid a division Guru Das Srinagesh
2020-04-22  2:57 ` [PATCH v13 09/11] backlight: pwm_bl: Use 64-bit division function Guru Das Srinagesh
2020-04-22  2:57   ` Guru Das Srinagesh
2020-04-22  2:57   ` Guru Das Srinagesh
2020-05-26  7:00   ` Lee Jones
2020-05-26  7:00     ` Lee Jones
2020-05-26  7:00     ` Lee Jones
2020-04-22  2:57 ` [PATCH v13 10/11] clk: pwm: " Guru Das Srinagesh
2020-04-25 19:06   ` Stephen Boyd
2020-04-22  2:57 ` [PATCH v13 11/11] pwm: core: Convert period and duty cycle to u64 Guru Das Srinagesh
2020-05-22 13:26   ` Uwe Kleine-König
2020-04-22  8:49 ` [PATCH v13 00/11] Convert PWM " Daniel Thompson
2020-04-22  8:49   ` [Intel-gfx] " Daniel Thompson
2020-04-22  8:49   ` Daniel Thompson
2020-04-22  8:49   ` Daniel Thompson
2020-04-22 23:37   ` Guru Das Srinagesh
2020-04-22 23:37     ` [Intel-gfx] " Guru Das Srinagesh
2020-04-22 23:37     ` Guru Das Srinagesh
2020-04-22 23:37     ` Guru Das Srinagesh
2020-04-23  9:20     ` Daniel Thompson
2020-04-23  9:20       ` [Intel-gfx] " Daniel Thompson
2020-04-23  9:20       ` Daniel Thompson
2020-04-23  9:20       ` Daniel Thompson
2020-04-23 11:48 ` Lee Jones
2020-04-23 11:48   ` [Intel-gfx] " Lee Jones
2020-04-23 11:48   ` Lee Jones
2020-04-23 11:48   ` Lee Jones
2020-04-23 21:53   ` Guru Das Srinagesh
2020-04-23 21:53     ` [Intel-gfx] " Guru Das Srinagesh
2020-04-23 21:53     ` Guru Das Srinagesh
2020-04-23 21:53     ` Guru Das Srinagesh
2020-04-24  6:43     ` Lee Jones
2020-04-24  6:43       ` [Intel-gfx] " Lee Jones
2020-04-24  6:43       ` Lee Jones
2020-04-24  6:43       ` Lee Jones
2020-04-24 22:14       ` Guru Das Srinagesh
2020-04-24 22:14         ` [Intel-gfx] " Guru Das Srinagesh
2020-04-24 22:14         ` Guru Das Srinagesh
2020-04-24 22:14         ` Guru Das Srinagesh
2020-04-27  6:44         ` Lee Jones
2020-04-27  6:44           ` [Intel-gfx] " Lee Jones
2020-04-27  6:44           ` Lee Jones
2020-04-27  6:44           ` Lee Jones
2020-05-20 23:15           ` Guru Das Srinagesh
2020-05-21  7:15             ` Lee Jones [this message]
2020-05-22 11:16               ` Thierry Reding
2020-05-22 11:31                 ` Lee Jones
2020-05-22 12:50                   ` Thierry Reding
2020-05-22 22:59                     ` Guru Das Srinagesh
2020-05-26  6:59                     ` Lee Jones
2020-04-24  6:45     ` Lee Jones
2020-04-24  6:45       ` [Intel-gfx] " Lee Jones
2020-04-24  6:45       ` Lee Jones
2020-04-24  6:45       ` Lee Jones
2020-04-24  6:46 ` Lee Jones
2020-04-24  6:46   ` [Intel-gfx] " Lee Jones
2020-04-24  6:46   ` Lee Jones
2020-04-24  6:46   ` Lee Jones

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=20200521071505.GL271301@dell \
    --to=lee.jones@linaro.org \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=collinsd@codeaurora.org \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel.thompson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=subbaram@codeaurora.org \
    --cc=thierry.reding@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.