lkml.org 
[lkml]   [2023]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: linux-next: duplicate patch in the nolibc tree
From
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

\
 
 \ /
  Last update: 2023-08-21 17:54    [W:0.067 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site