Re: RFC improving amount of content in 5.11

[Tom Rix <trix@redhat.com>]

On 9/15/20 2:33 PM, Moritz Fischer wrote:
> 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.

We agree slow reviews are throttling the content in the releases.

Is this a temporary situation with your work or is it steady state?


Are slow reviews the only problem ?

Which is getting back to my original RFC on how can we improve the amount of content in the releases ?

Tom

>
> - Moritz
>