Re: RFC improving amount of content in 5.11

[Moritz Fischer <mdf@kernel.org>]

Tom,

On Tue, Sep 15, 2020 at 01:58:52PM -0700, Tom Rix wrote:

> A non trival change takes 8 revisions, with about 1 week per revision.

I don't consider that to be out of the norm, especially if you want
multiple people to give feedback on a changeset. This is a result of the
distributed nature of people working across several timezones.

I generally prefer to go a bit slower and get it right rather than
having to redo or realize we got the interfaces wrong -- some of which
have to stay stable.

> Gives us 1 or 2 changes per release.
> 
> In the easy case, a new card is in the same family, will have 4 new ip blocks
> 
> and a change to glue it all together change, 5 patch sets.

So far I haven't seen that happen that many times.

> So we can handle 1 or 2 cards year.

Again I haven't seen more than that in the past.
> 
> But if we can cut the review down to 2 weeks, we could do maybe 5-10 cards per year.
> 
> 
> Then the downside if we do not keep up.
> 
> every card has a custom out of tree driver available on a limited set of distros.
> 
> which i believe is the current state of things.

Tbh, this is easy to fix as vendor by just submitting the code earlier
and in smaller chunks. People can send out RFCs early and then we can
discuss designs and not just show up with 20+ patch series and expect them
to be merged as is (ideally within 2-3 revisions) even more so if they
span several subsystems.

The kernel never has cared about corporate timelines, and as vendor if
you care about timely hardware support (and want to avoid out-of-tree
nightmares) start early with your upstreaming efforts. That has always
been the case.

> >> So I was wondering what we can do generally and i can do specifically
> >> to improve this.
> >>
> >> My comment
> >> Though we are a low volume list, anything non trivial takes about 8 revisions.
> >> My suggestion is that we all try to give the developer our big first
> >> pass review within a week of the patch landing and try to cut the
> >> revisions down to 3.
> > It's unfortunate that it takes so long to get things moving, I agree,
> > but with everything that's going on - bear in mind people deal different
> > with situations like the present - it is what it is.
> >
> > My current dayjob doesn't pay me for working on this so the time I dedicate
> > to this comes out of my spare time and weekends - Personally I'd rather
> > not burn out and keep functioning in the long run.
> 
> I understand, in the past i have worked as a maintainer when it was not my day job, it's hard.
> 
> I am fortunate, fpga kernel and userspace is my day job.  Over the last couple of months, i have been
> 
> consistently spending a couple hours a day fixing random kernel problems as well as getting linux-fpga
> 
> reviews out within a day or two so i know i have the bandwidth to devote.
> 
> 
> So I am asking what else can I do ?
> 
> Would helping out with staging the PR's be help ?

As you pointed out above, the bottleneck is review velocity, I don't
know what staging PRs helps with that.

> 
> Could i move up to a maintainer ?

The problem is I'd still like to review the patches that go into my
subsystem. I appreciate your help with the reviews, and it's been
helpful so far. I don't think having an addtional maintainer will help
with that at this point.

- Moritz