Date:   Mon, 21 Aug 2023 09:52:56 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Christian Brauner <brauner@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>, Willy Tarreau <w@....eu>
Cc:     Thomas Weißschuh <thomas@...ch.de>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: linux-next: duplicate patch in the nolibc tree

On 8/18/23 07:59, Shuah Khan wrote:
> On 8/18/23 07:27, Christian Brauner wrote:
>> On Thu, Aug 17, 2023 at 01:41:45PM -0700, Paul E. McKenney wrote:
>>> On Thu, Aug 17, 2023 at 09:39:09PM +0200, Willy Tarreau wrote:
>>>> On Thu, Aug 17, 2023 at 11:46:57AM -0700, Paul E. McKenney wrote:
>>>>> On Thu, Aug 17, 2023 at 12:27:46PM -0600, Shuah Khan wrote:
>>>>>> On 8/17/23 10:30, Thomas Weißschuh wrote:
>>>>>>> On 2023-08-17 13:38:11+1000, Stephen Rothwell wrote:
>>>>>>>> The following commit is also in the vfs-brauner tree as a different commit
>>>>>>>> (but the same patch):
>>>>>>>>
>>>>>>>>     ba859b2e419c ("selftests/nolibc: drop test chmod_net")
>>>>>>>>
>>>>>>>> This is commit
>>>>>>>>
>>>>>>>>     49319832de90 ("selftests/nolibc: drop test chmod_net")
>>>>>>>>
>>>>>>>> in the vfs-brauner tree.
>>>>>>>
>>>>>>> I think we can drop the patch from the nolibc tree.
>>>>>>> The patch is only really necessary in combination with
>>>>>>> commit 18e66ae67673 ("proc: use generic setattr() for /proc/$PID/net")
>>>>>>> which already is and should stay in the vfs tree.
>>>>>>
>>>>>> Thomas,
>>>>>>
>>>>>> Do the rest of the nolibc patches build without this if we were
>>>>>> to drop this patch? Dorpping requires rebase and please see below.
>>>>>>
>>>>>> Willy, Paul,
>>>>>>
>>>>>> How do we want to handle this so we can avoid rebasing to keep
>>>>>> the Commit IDs the same as one ones in Willy's nolibc branch?
>>>>>
>>>>> The usual way would be for Willy to drop the patch, rebase, and republish
>>>>> his branch.  You would then discard the current branch and pull the
>>>>> new one.
>>>>>
>>>>>> I would recommend dropping this commit from vfs-brauner if it
>>>>>> doesn't cause problems.
>>>>>
>>>>> It might be good for nolibc patches to be going through Willy's tree.
>>>>
>>>> It would indeed be more logical as a general rule. However, here I don't
>>>> care as I don't see any issue caused by dropping it, I can adapt to what
>>>> is most convenient for most of us.
>>>>
>>>> Let's maybe just wait a little bit for Christian to suggest what he
>>>> prefers then we can adapt.
>>>>
>>>>> Or does Christian have some situation where it is necessary to make
>>>>> a coordinated vfs/nolibc change?
>>>>
>>>> I don't think there's any need for coordination on this one.
>>>
>>> It is always good when either option can be make to work.  ;-)
>>
>> The patch in the vfs tree will make the test fail so it makes sense to
>> have both go in together. I would normally be happy to drop it but I'm
>> rather unenthusiastic in this particular case because I replied to this
>> almost 5 weeks ago on Thursday, July 13 and since then this has been in
>> -next.
>>
> 
> I totally understand you being unenthusiastic. Considering summer
> vacation schedules and all, emails get missed at times.
> 
> I sincerely request you to consider dropping as it is the simpler route
> for all involved.
> 

Christian,

Please let us know if my request failed to raise your enthusiasm level.
We will go to our plan b of having Willy drop the patch, resend the
pull request to me ....


thanks,
-- Shuah

Powered by blists - more mailing lists