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.
Cheers,
Willy
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