On Mon, Jul 26, 2021 at 12:18 PM <[email protected]> wrote:
> On 23.07.2021 12:13, Uwe Kleine-König wrote:
> > From:
> > Uwe Kleine-König <[email protected]>
> > Date:
> > 23.07.2021, 12:13
> > On Wed, Jun 09, 2021 at 10:21:23PM +0200, Uwe Kleine-König wrote:
> >> given that I don't succeed in getting any feedback for my patch set, I'm
> >> trying with a pull request today.
> > This is for a series that is currently in v7 and didn't get any feedback
> > at all yet. The history is:
> >
> > v1: 2020-10-13, https://lore.kernel.org/linux-clk/[email protected]
> > no feedback at all
> >
> > v2: 2021-03-01, https://lore.kernel.org/linux-clk/[email protected]
> > kernel test robot identified some issues
> >
> > v3: 2021-03-01, https://lore.kernel.org/linux-clk/[email protected]
> > I added a few driver patches to show the benefit. (However in a way
> > that the autobuilders don't understand, so there were some false
> > positive build failure reports.)
> >
> > v4: 2021-03-30, https://lore.kernel.org/linux-clk/[email protected]
> > Got some feedback for the converted drivers by the respective
> > maintainers. Some were indifferent, some found it good
> >
> > v5: 2021-04-22, https://lore.kernel.org/linux-clk/[email protected]
> > Fixed a problem in one of the driver changes (i2c-imx), no feedback
> > apart from pointing out a few typos, silence from the clk
> > maintainers
> >
> > v6: 2021-04-26, https://lore.kernel.org/linux-clk/[email protected]
> > Just the typos fixed, no feedback
> >
> > v6 resend: 2021-05-10, https://lore.kernel.org/linux-clk/[email protected]
> > no changes in code. Got some feedback from Jonathan Cameron
> >
> > v7: 2021-05-10, https://lore.kernel.org/linux-clk/[email protected]
> > Adress Jonathan's feedback, recieved some more acks from non-clk
> > people
> >
> > pull request: 2021-07-09, https://lore.kernel.org/linux-clk/[email protected]
> >
> > On Fri, Jul 23, 2021 at 11:26:58AM +0300, Andy Shevchenko wrote:
> >> On Thursday, July 22, 2021, Wolfram Sang <[email protected]> wrote:
> >>
> >>>>> What about adding gkh to the list explaining the situation to him?
> >>>> Greg doesn't like devm_ stuff.
> >>>>
> >>>> I already asked Arnd who doesn't want to interfere and akpm who didn't
> >>>> react either up to now.
> >>> Wow, okay, that is frustrating.
> >> The situation simply shows the process gap and One Maintainer nowadays is
> >> far from enough to satisfy demands.
> > Technically there are two maintainers for drivers/clk, Michael Turquette
> > and Stephen Boyd. It seems Michael is MIA and Stephen doesn't have the
> > capacity to address all requests.
> >
> >> What I think about is that we need to escalate this to Linus and
> >> others and elaborate the mechanisms how to squeeze a new (additional)
> >> maintainer when the original one is not responsive. Let’s say some
> >> procedural steps. Otherwise we doomed because of human factor.
> > Assuming there was some process for this, is there someone who is
> > willing to take responsibility here?
>
> Hi,
>
> In the last year I worked on AT91 clock drivers and I would be available
> for taking responsibility beyond AT91 clocks (if everyone's OK with this),
> in whatever form the current maintainers and people in the audience would
> agree, if any (co-maintainer or other forms that could be useful). The idea
> is to help things progress as I also have patches waiting for feedback on
> clock mailing list for almost 6 months.
>
> Let me know if I can be helpful.
I think so. Many subsystems relatively recently (in the last couple of
years or so) enforced that new drivers have to have official
maintainers. Besides that it's warmly welcome to register existing
drivers in the MAINTAINERS database. I would tell you go ahead and
become a maintainer of AT91 clocks and it will definitely reduce the
burden on Stephan's shoulders.
The idea is that you will send a PR to CCF maintainers instead of
patches, although it's expected that patches appear in the mailing
list beforehand anyway.
--
With Best Regards,
Andy Shevchenko
> The idea is that you will send a PR to CCF maintainers instead of
> patches, although it's expected that patches appear in the mailing
> list beforehand anyway.
Depends a little. For me, a Rev-by from the driver maintainer is enough,
and I'll pick them. That lowers the burden on the drivers maintainer
side. May not work for high volumes of patches, but for I2C this works
enough.
On Mon, Jul 26, 2021 at 3:33 PM Wolfram Sang <[email protected]> wrote:
>
>
> > The idea is that you will send a PR to CCF maintainers instead of
> > patches, although it's expected that patches appear in the mailing
> > list beforehand anyway.
>
> Depends a little. For me, a Rev-by from the driver maintainer is enough,
> and I'll pick them. That lowers the burden on the drivers maintainer
> side. May not work for high volumes of patches, but for I2C this works
> enough.
AFAICT in practice it's a mandatory requirement in I²C subsys (in the
past you hadn't accepted a patch from us without a tag from the
maintainer) which makes it equal to sending PR by a maintainer. PR
makes less burden since subsys maintainer don't need to run many tools
or a tool many times to get the pile of patches.
--
With Best Regards,
Andy Shevchenko
> AFAICT in practice it's a mandatory requirement in I²C subsys (in the
> past you hadn't accepted a patch from us without a tag from the
> maintainer) which makes it equal to sending PR by a maintainer. PR
Right. I require a tag from the driver maintainer.
> makes less burden since subsys maintainer don't need to run many tools
> or a tool many times to get the pile of patches.
I had driver maintainers who found it difficult to have a public tree to
pull from or forgot how to send properly prepared pull requests. They
were happy to send Rev-by, though. And I am happy with that, too. At
least in I2C, picking up patches is small work compared to the actual
review.