All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-pwm@vger.kernel.org, kernel@pengutronix.de
Subject: Re: Missing feedback
Date: Fri, 22 May 2020 13:46:35 +0200	[thread overview]
Message-ID: <20200522114635.GB2163848@ulmo> (raw)
In-Reply-To: <20200522101355.x4td3ehkfhp636ft@pengutronix.de>

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

On Fri, May 22, 2020 at 12:13:55PM +0200, Uwe Kleine-König wrote:
> Hello Thierry,
> 
> there is again quite a backlog of missing pwm feedback and missing care
> for patchwork.
> 
> Patchwork has several iterations of a few patch series where the old
> series should be marked as superseeded. If you want you can give me
> write access there, then I can go through the list and mark patches
> accordingly. (I'm user "ukleinek" on patchwork.ozlabs.org.)
> 
> Patches/mails where I'd like to see feedback (or just application) from
> you include:
> 
>  - "Convert PWM period and duty cycle to u64" series (v14, feedback)
>  - pwm: sun4i: direct clock output support for Allwinner A64 (v2, 
>    application)
>  - pwm: imx27: Fix rounding behavior
>  - docs: pwm: rework documentation for the framework
>  - adding linux-pwm archives to lore.kernel.org?
> 
> but I feel the backlog on the list is much bigger.
> 
> In the past I did less review on the list myself, partly because I
> consider it frustrating to invest time and then still have patches lying
> around without application/feedback.

To be honest, I've been feeling this way for a number of years now. PWM
isn't exactly very "hot" and it's difficult to get much of a reaction
from anyone. You do get a reaction when you apply patches that nobody's
been willing to review or test and then they end up breaking things and
people only notice when they're updating their product kernels to a new
version and by that time it's becoming really difficult to fix things.

On top of that I've been having trouble finding any time to spend on PWM
maintenance because in addition to a fulltime job (which doesn't include
PWM work) now I have two kids that need to be homeschooled. This may or
may not get better in the weeks or months ahead. Now, don't get me wrong
because I know there are plenty of other people that are struggling with
the situation, so I know this is difficult for everyone. Just saying how
things are for me and why I can barely find any time to spend on PWM.

The lack of participation isn't very uncommon for subsystems such as PWM
and I've seen other subsystem maintainers voice the same frustrations
over the years. I'm not sure what a good solution to this is. Some have
tried a group maintainership model with some success, at other times it
might just be time for someone else to take over.

To be honest, I have occasionally considered just abandonning PWM and
let somebody else take over. Until recently this wasn't really an option
because there was nobody else showing any interest and doing an okay job
of it seemed like a better idea than orphaning and letting someone else
with already too much work handle the patches. It's not like the review
situation would improve that way either.

> I think getting patchwork more up to date would already help
> considerably, but in the long run I can also imagine taking care for
> patch application and sending pull requests if this helps.

I very much appreciate your help on reviewing patches. At the same time,
even while you certainly have shown an interest in the PWM subsystem for
a while, if you're already frustrated by the lack of progress, even
though that may be partially my own fault, I'm not convinced the
subsystem is going to be in much better hands if I were to leave it all
to you. It sometimes may seem like a trivial job, but it's also very
frustrating because people really only tend to get mad at you for any
number of reasons. People take it for granted that you will be there to
support them and offer little to no support in return. They will also
sometimes completely overwhelm you with patches and won't even let you
review patches before they send out new versions.

What they don't realize is that that actually doesn't improve the
situation because it keeps adding to your maintainer work queue. You
mention patchwork, and while it's a great tool, having to go through it
and mark all of those patch series that you haven't even looked at as
"superseeded" is tedious work and takes away precious time that you
can't use to actually do review.

Anyway, I don't want to discourage you or anything, just want to give
you a fair warning about the differences of being a contributor/reviewer
and a maintainer. If you're really serious about being more active, do
you have any concrete suggestions on what would help? Should we maybe
start by giving you access to patchwork so that you can mark patches and
keep it in a better state?

Another option might be for us to share patch application, though that's
honestly the least time-consuming part. Once patches are reviewed and
ready, it's easy for me to apply and push out a new tree, so it's not
like sharing the workload would be much help.

Like I said, I'm open to let you take on a more central role eventually,
but I'm going to need a bit more time to convince myself that you will
be doing a better job than I.

Thierry

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

  reply	other threads:[~2020-05-22 11:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22 10:13 Missing feedback Uwe Kleine-König
2020-05-22 11:46 ` Thierry Reding [this message]
2020-05-22 13:15   ` Uwe Kleine-König
2020-05-22 15:21     ` Thierry Reding
2020-05-22 17:33       ` 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=20200522114635.GB2163848@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=kernel@pengutronix.de \
    --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 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.