Linux PWM subsystem development
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-pwm@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH 00/14] pwm: Patches I consider ready for the next merge window
Date: Tue, 23 Mar 2021 09:53:55 +0100	[thread overview]
Message-ID: <YFmso17v2N270Dd+@orome.fritz.box> (raw)
In-Reply-To: <20210323071929.GD2916463@dell>

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

On Tue, Mar 23, 2021 at 07:19:29AM +0000, Lee Jones wrote:
> On Mon, 22 Mar 2021, Thierry Reding wrote:
> 
> > On Fri, Mar 19, 2021 at 11:28:38AM +0100, Uwe Kleine-König wrote:
> > > Hello,
> > > 
> > > this is the set of patches that are open on the list for some time.
> > > Lee suggested to resend them.
> > > 
> > > @Thierry: I'm unsure what is the best way to nag. Is it really
> > > resending? Or does this just result mostly in overhead because the
> > > patches are still open in patchwork and it adds copies to your mailbox?
> > > (Another downside is that taking the patches from this thread results in
> > > recording a newer Author Date compared to picking up the originals.)
> > 
> > I use patchwork extensively for tracking, so merely resending patches so
> > that they float to the top of my inbox isn't useful in itself. Patches
> > do, by the way, float to the top of my inbox when you just reply to them
> > (e.g. by pinging). Resending a particular series is fine because it's
> > then easy to mark the old version as "superseded". Sending a collection
> > of patch such as this is a bit more annoying because now the duplicates
> > are spread about a bit more in patchwork, so it's a bit more work to get
> > patchwork cleaned up. But it's not that bad, so no harm done.
> > 
> > Usually when I look at patchwork I will look at the A/F/R/T column and
> > the more flags I see there, the more likely I will be to go and apply
> > it. Anything else I will go and look at myself and comment and/or apply
> > or sometimes wait for someone else to review.
> > 
> > Perhaps a better way to nag me would be to delegate patches that you've
> > reviewed or think are ready to me, which would make them stand out more
> > among the others.
> 
> It's not Uwe's fault, it's mine.
> 
> Since some of Uwe's patches had been left unreviewed for several
> weeks, I asked him to collect up all of his dangling patches and
> submit this resend for *me* to review.

Like I said, it's not a big deal. And I'm also aware that this is misery
of my own making, so no worries.

> As someone who does not use Patchwork, I find this to be the simplest
> and cleanest method of patch collation.  Going by your almost
> immediate reply, I guess it had a nice desired side-effect. :)

Indeed, it achieved the desired effect, so can't argue about its
effectiveness. =)

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-03-23  8:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-19 10:28 [PATCH 00/14] pwm: Patches I consider ready for the next merge window Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 01/14] pwm: bcm2835: Improve period and duty cycle calculation Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 02/14] pwm: bcm-kona: Use pwmchip_add() instead of pwmchip_add_with_polarity() Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 03/14] pwm: atmel-hlcdc: " Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 04/14] pwm: Drop function pwmchip_add_with_polarity() Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 05/14] pwm: ab8500: Implement .apply instead of .config, .enable and .disable Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 06/14] pwm: imx-tpm: Use a single line for error message Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 07/14] pwm: Always allocate pwm id dynamically Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 08/14] pwm: Return -EINVAL for old-style drivers without .set_polarity callback Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 09/14] pwm: Prevent a glitch in compat code Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 10/14] pwm: atmel-tcb: Implement .apply callback Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 11/14] pwm: atmel-tcb: Only free resources after pwm_chip_remove() returned Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 12/14] pwm: sprd: Refuse requests with unsupported polarity Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 13/14] pwm: cros-ec: " Uwe Kleine-König
2021-03-19 10:28 ` [PATCH 14/14] pwm: Soften potential loss of precision in compat code Uwe Kleine-König
2021-03-22 13:26 ` [PATCH 00/14] pwm: Patches I consider ready for the next merge window Thierry Reding
2021-03-22 14:00   ` Uwe Kleine-König
2021-03-23  7:19   ` Lee Jones
2021-03-23  8:53     ` Thierry Reding [this message]
2021-03-23  9:02       ` Lee Jones
2021-04-08 10:43     ` Uwe Kleine-König

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=YFmso17v2N270Dd+@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-pwm@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox