From: Lee Jones <lee.jones@linaro.org>
To: Thierry Reding <thierry.reding@gmail.com>
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:02:52 +0000 [thread overview]
Message-ID: <20210323090252.GI2916463@dell> (raw)
In-Reply-To: <YFmso17v2N270Dd+@orome.fritz.box>
On Tue, 23 Mar 2021, Thierry Reding wrote:
> 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. =)
=:D
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2021-03-23 9:03 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
2021-03-23 9:02 ` Lee Jones [this message]
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=20210323090252.GI2916463@dell \
--to=lee.jones@linaro.org \
--cc=kernel@pengutronix.de \
--cc=linux-pwm@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox