lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18989954-981e-46bb-a60b-973c1c58fd86@paulmck-laptop>
Date:   Thu, 24 Aug 2023 04:45:36 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     Thomas Weißschuh <thomas@...ch.de>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Ryan Roberts <ryan.roberts@....com>
Subject: Re: linux-next: manual merge of the nolibc tree with the mm-stable
 tree

On Thu, Aug 24, 2023 at 08:48:26AM +0200, Willy Tarreau wrote:
> Hi Thomas,
> 
> On Thu, Aug 24, 2023 at 08:41:18AM +0200, Thomas Weißschuh wrote:
> > Hi everybody,
> > 
> > On 2023-08-17 13:30:53+1000, Stephen Rothwell wrote:
> > > Today's linux-next merge of the nolibc tree got a conflict in:
> > > 
> > >   tools/include/nolibc/stdio.h
> > > 
> > > between commit:
> > > 
> > >   08d959738a95 ("selftests: line buffer test program's stdout")
> > > 
> > > from the mm-stable tree and commits:
> > > 
> > >   65ff4d19f792 ("tools/nolibc/stdio: add setvbuf() to set buffering mode")
> > >   2e00a8fc4f47 ("tools/nolibc: setvbuf: avoid unused parameter warnings")
> > > 
> > > from the nolibc tree.
> > >
> > > I fixed it up (I just used the latter version of this file) and can
> > > carry the fix as necessary. This is now fixed as far as linux-next is
> > > concerned, but any non trivial conflicts should be mentioned to your
> > > upstream maintainer when your tree is submitted for merging.  You may
> > > also want to consider cooperating with the maintainer of the conflicting
> > > tree to minimise any particularly complex conflicts.
> > 
> > how do we want to handle this one?
> > 
> > A small note to Linus in the PRs to him on how to resolve it seem
> > reasonable to me.
> > But I'm fairly new to the process.
> 
> My understanding is that Stephen's fix is still in his tree. We may indeed
> need to add a note to Linus in the PR about this one and the other one.

Yes, this is the usual approach.  The note to Linus normally includes the
URL for Stephen's email.  I usually also do the merge myself, publish
a branch to it, and include the name of that branch in my pull request
to Linus.  Linus usually prefers to resolve the merge conflicts himself,
but my merge gives him something to compare against.

							Thanx, Paul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ