Re: Maintenance of Linux/MIPS?

[Matt Redfearn <matt.redfearn@imgtec.com>]

On 26/08/17 00:14, David Daney wrote:
> On 08/25/2017 04:07 PM, Paul Burton wrote:
>> Hello,
>>
>> On Friday, 25 August 2017 14:21:33 PDT Florian Fainelli wrote:
>>> Hi,
>>>
>>> There are a lot of patches at
>>> https://patchwork.linux-mips.org/project/linux-mips/list/ that 
>>> appear to
>>> be under the "New" state and have not had a chance to be reviewed yet.
>>>
>>> What can we do to help speed up the review process, do we need more
>>> reviewers? It seems like most patches affecting Linux/MIPS are still
>>> core MIPS kernel changes, but would it help if say, people were queuing
>>> SoC/board specific patches in trees and submit pull requests? Would 
>>> that
>>> help lower the amount of patches to review?
>>>
>>> Any other suggestion?
>>>
>>> Thanks!
>>
>> Personally I think it'd probably be good if Ralf were willing to 
>> formally
>> share maintainership duties with someone else or a group of people. I 
>> think
>> James for example would be a great choice, and already dons a 
>> maintainer hat.
>
> FWIW, I agree.  James has a lot of experience here and has served as 
> maintainer when Ralf was away in the past.  Making him a permanent 
> co-maintainer, or similar, with the explicit mandate of getting 
> patches upstream to Linus, would be beneficial to all who rely on the 
> MIPS Linux kernel.
>
> David.

I'd add my vote to having James as a co-maintainer, which should help 
lower the burden on Ralf and hopefully lead to a faster 
time-to-upstream, as currently quite a few series have required 
respinning simply because the kernel has moved on while they wait and 
the patches have bitrotted.

Matt

>
>
>
>>
>> As-is Ralf ends up being a bottleneck a lot of the time, and the 
>> backlog in
>> patchwork is pretty good evidence of that. There are a whole lot of 
>> patches
>> that ought to be going into v4.14, and that ought to be sat in 
>> linux-next
>> right now in preparation for that. Sadly not many of them are, and 
>> usually
>> that remains the case until very close to the merge window. Sharing 
>> the load
>> could only help with this.
>>
>> Thanks,
>>      Paul
>>
>
>