Message-ID: <dccc8075-b900-8680-3620-8050475858a7@redhat.com>
Date:   Mon, 11 Jan 2021 11:46:03 -0800
From:   Tom Rix <trix@...hat.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Moritz Fischer <mdf@...nel.org>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        linux-kernel@...r.kernel.org, moritzf@...gle.com,
        Rikard Falkeborn <rikard.falkeborn@...il.com>,
        Zheng Yongjun <zhengyongjun3@...wei.com>,
        Russ Weight <russell.h.weight@...el.com>,
        "Gerlach, Matthew" <matthew.gerlach@...el.com>,
        Sonal Santan <sonal.santan@...inx.com>,
        Xu Yilun <yilun.xu@...el.com>,
        Richard Gong <richard.gong@...el.com>
Subject: Re: [PATCH 0/8] FPGA DFL Changes for 5.12


On 1/11/21 10:21 AM, Greg KH wrote:
> On Mon, Jan 11, 2021 at 08:43:15AM -0800, Tom Rix wrote:
>> On 1/11/21 8:09 AM, Greg KH wrote:
>>> On Mon, Jan 11, 2021 at 07:55:24AM -0800, Tom Rix wrote:
>>>> On 1/11/21 6:54 AM, Greg KH wrote:
>>>>> On Mon, Jan 11, 2021 at 06:40:24AM -0800, Tom Rix wrote:
>>>>>> On 1/10/21 10:57 PM, Greg KH wrote:
>>>>>>> On Sun, Jan 10, 2021 at 11:43:54AM -0800, Tom Rix wrote:
>>>>>>>> On 1/10/21 9:05 AM, Moritz Fischer wrote:
>>>>>>>>> Tom,
>>>>>>>>>
>>>>>>>>> On Sun, Jan 10, 2021 at 07:46:29AM -0800, Tom Rix wrote:
>>>>>>>>>> On 1/7/21 8:09 AM, Tom Rix wrote:
>>>>>>>>>>> On 1/6/21 8:37 PM, Moritz Fischer wrote:
>>>>>>>>>>>> This is a resend of the previous (unfortunately late) patchset of
>>>>>>>>>>>> changes for FPGA DFL.
>>>>>>>>>>> Is there something I can do to help ?
>>>>>>>>>>>
>>>>>>>>>>> I am paid to look after linux-fpga, so i have plenty of time.
>>>>>>>>>>>
>>>>>>>>>>> Some ideas of what i am doing now privately i can do publicly.
>>>>>>>>>>>
>>>>>>>>>>> 1. keep linux-fpga sync-ed to greg's branch so linux-fpga is normally in a pullable state.
>>>>>>>>> Is it not? It currently points to v5.11-rc1. If I start applying patches
>>>>>>>>> that require the changes that went into Greg's branch I can merge.
>>>>>>>> I mean the window between when we have staged patches and when they go into Greg's branch.
>>>>>>>>
>>>>>>>> We don't have any now, maybe those two trival ones.
>>>>>>>>
>>>>>>>> Since Greg's branch moves much faster than ours, our staging branch needs to be rebased regularly until its merge.
>>>>>>> Ick, no!  NEVER rebase a public branch.  Why does it matter the speed of
>>>>>>> my branch vs. anyone elses?  Git handles merges very well.
>>>>>>>
>>>>>>> Just like Linus's branches move much faster than mine, and I don't
>>>>>>> rebase my branches, you shouldn't rebase yours.
>>>>>>>
>>>>>>> Becides, I'm only taking _PATCHES_ for fpga changes at the moment, no
>>>>>>> git pulls, so why does it matter at all for any of this?
>>>>>>>
>>>>>>> What is the problem you are trying to solve here?
>>>>>> This 5.12 fpga patchset not making it into 5.11.
>>>>> Ok, but isn't it the responsibility of the submitter to make sure they
>>>>> apply properly when sending them out?
>>>>>
>>>>>> At some point before the 5.11 window, I tried it on next and it failed to merge.
>>>>>>
>>>>>> This points to needing some c/i so it does not happen again.
>>>>> "again"?  Merges and the like are a totally normal thing and happen all
>>>>> the time, I still fail to understand what you are trying to "solve" for
>>>>> here...
>>>> What can I do to help make your merges as easy as possible ?
>>> I have not had any problems with merges, I've only had "problems"
>>> rejecting patches for their content.
>>>
>>> Try helping out with patch reviews if you want, finding and fixing
>>> things before I review them is usually a good idea :)
>> ok.
>>>> Does the patchwork infra Moritz was speaking of earlier need fixing help?
>>> No idea, I don't use it.
>>>
>>>> Any other things ?
>>> What problems are you trying to solve here?  What's wrong with how this
>>> subsystem is working that you are feeling needs to be addressed?
>> I do not believe the issue I raised in 5.10 has made any progress.
> What issue?
>
>> If you look at the content in 5.11 we have actually regressed.
> What bugs regressed?
>
>> https://lore.kernel.org/linux-fpga/3295710c-5e82-7b97-43de-99b9870a8c8c@redhat.com/
> I don't see the problem here, other than a low-quality of patches that
> need reworking for some patchsets, and others are just fine.  Just like
> all kernel subsystems, I don't see anything odd here.
>
>> Over the last two releases, I have shown i have the time and interest to maintain this subsystem.
> That's not how any of this works :)
>
>> So I am asking for
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 11b38acb4c08..269cd08f4969 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6951,7 +6951,7 @@ F:        drivers/net/ethernet/nvidia/*
>>  
>>  FPGA DFL DRIVERS
>>  M:     Wu Hao <hao.wu@...el.com>
>> -R:     Tom Rix <trix@...hat.com>
>> +M:     Tom Rix <trix@...hat.com>
> That's generous, but how about doing review first, the maintainership of
> this subsystem does not feel like any sort of bottleneck to me.  I
> personally have no problems with Moritz's interactions with the
> community, his reviewing of patches, and forwarding on to me.
>
> Of course we all have delays as we have other work to do than just this,
> that's just part of normal development.  I don't see anything stalled at
> the moment, nor anything that having another maintainer would have
> helped out with at all, so this feels like it is not needed from my end.
>
> Again, it feels like the developers need more reviews, and good ones, so
> please continue to help out with that, as that's the best thing I can
> see to do here.

I have been doing the first review in a couple of days after every patch landing.

I see some pretty good response from the developers to fix the issues raised. 

But I do not see Moritz picking up the review until weeks later.

This consistent delay in timely reviews is a bottleneck.

It would be good if the big first reviews could be done in parallel.

Tom

>
> thanks,
>
> greg k-h
>

Powered by blists - more mailing lists