All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Olof Johansson <olof@lxom.net>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	David Miller <davem@davemloft.net>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Paul Lawrence <paullawrence@google.com>,
	Sandipan Das <sandipan@linux.vnet.ibm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Will Deacon <will.deacon@arm.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Paul Burton <paul.burton@mips.com>,
	David Rientjes <rientjes@google.com>, Willy Tarreau <w@1wt.eu>,
	Martin Sebor <msebor@gmail.com>,
	Christopher Li <sparse@chrisli.org>,
	Jonathan Corbet <corbet@lwn.net>, "Ted Ts'o" <tytso@mit.edu>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Joe Perches <joe@perches.com>, Arnd Bergmann <arnd@arndb.de>,
	Stefan Agner <stefan@agner.ch>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	linux-sparse@vger.kernel.org, linux-kbuild@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL linux-next] Add Compiler Attributes tree
Date: Wed, 3 Oct 2018 14:34:28 +0200	[thread overview]
Message-ID: <CANiq72nLLhTf3AsXqLkPmK6TV_g7E3tML9XaM_zE45dM7XPn-A@mail.gmail.com> (raw)
In-Reply-To: <20181003090010.5150f914@canb.auug.org.au>

Hi Stephen,

On Wed, Oct 3, 2018 at 1:00 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Miguel,
>
> On Wed, 3 Oct 2018 00:36:52 +0200 Dominique Martinet <asmadeus@codewreck.org> wrote:
> >
> > Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > > As I have read, -next is supposed to be a vision of what the merge
> > > window will look like after merging everything, i.e. ideally -rc1. For
> > > that to work for files out-of-tree (like these ones, which are not
> > > maintained by a single tree), changes should be allowed to be stacked
> > > on each other; otherwise, we cannot handle conflicts :-(
> >
> > The rule is the same as with a regular mainline pull; I don't have the
> > reference at hand but in some recent-ish pull request Linus said he
> > prefers the stable version with the conflict, and optionally you can
> > provide a second branch with the conflict resolved for reference, but
> > the pull request should be based on something stable even if it has
> > conflicts
> >
> > If there is a conflict Stefen will resolve it like Linus/Greg would, and
> > the resolved bit will be carried over everyday so it's not much more
> > work -- exactly like a regular pull request for inclusion in the main
> > tree :)
>
> Exactly what Dominique said.  I will fix up the conflict (unless it is
> a very complex conflict, in which case the author(s) should help) and
> the Linus (or Greg) will do the same.  If you do depend on a patch in
> Andrew's series, what happens if that patch does not get sent to Linus
> during the merge window or Linus rejects it?

This doesn't depend on anything. Not sure what is all the fuss about
-- people got confused into thinking we had to drop a patch for some
reason. As explained in the first email, I simply rebased v5 (which is
based on top of rcX) to resolve the conflict myself (i.e. it does
*not* depend on changes in -next). If you are the one solving
conflicts yourself (which is what I asked in my second email), there
is no problem to begin with; I will simply send v6 to you and we are
done.

When I sent the first email, I assumed that changes in -next were
supposed to be clean -- my mistake, but please document somewhere how
-next works! Specially that you are rerere'ing conflicts and
re-resolving them every day.

Then the discussion shifted to what to do with changes that actually
depend on other changes.

Cheers,
Miguel

WARNING: multiple messages have this Message-ID (diff)
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Olof Johansson <olof@lxom.net>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	David Miller <davem@davemloft.net>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>,
	Paul Lawrence <paullawrence@google.com>
Subject: Re: [GIT PULL linux-next] Add Compiler Attributes tree
Date: Wed, 3 Oct 2018 14:34:28 +0200	[thread overview]
Message-ID: <CANiq72nLLhTf3AsXqLkPmK6TV_g7E3tML9XaM_zE45dM7XPn-A@mail.gmail.com> (raw)
In-Reply-To: <20181003090010.5150f914@canb.auug.org.au>

Hi Stephen,

On Wed, Oct 3, 2018 at 1:00 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Miguel,
>
> On Wed, 3 Oct 2018 00:36:52 +0200 Dominique Martinet <asmadeus@codewreck.org> wrote:
> >
> > Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > > As I have read, -next is supposed to be a vision of what the merge
> > > window will look like after merging everything, i.e. ideally -rc1. For
> > > that to work for files out-of-tree (like these ones, which are not
> > > maintained by a single tree), changes should be allowed to be stacked
> > > on each other; otherwise, we cannot handle conflicts :-(
> >
> > The rule is the same as with a regular mainline pull; I don't have the
> > reference at hand but in some recent-ish pull request Linus said he
> > prefers the stable version with the conflict, and optionally you can
> > provide a second branch with the conflict resolved for reference, but
> > the pull request should be based on something stable even if it has
> > conflicts
> >
> > If there is a conflict Stefen will resolve it like Linus/Greg would, and
> > the resolved bit will be carried over everyday so it's not much more
> > work -- exactly like a regular pull request for inclusion in the main
> > tree :)
>
> Exactly what Dominique said.  I will fix up the conflict (unless it is
> a very complex conflict, in which case the author(s) should help) and
> the Linus (or Greg) will do the same.  If you do depend on a patch in
> Andrew's series, what happens if that patch does not get sent to Linus
> during the merge window or Linus rejects it?

This doesn't depend on anything. Not sure what is all the fuss about
-- people got confused into thinking we had to drop a patch for some
reason. As explained in the first email, I simply rebased v5 (which is
based on top of rcX) to resolve the conflict myself (i.e. it does
*not* depend on changes in -next). If you are the one solving
conflicts yourself (which is what I asked in my second email), there
is no problem to begin with; I will simply send v6 to you and we are
done.

When I sent the first email, I assumed that changes in -next were
supposed to be clean -- my mistake, but please document somewhere how
-next works! Specially that you are rerere'ing conflicts and
re-resolving them every day.

Then the discussion shifted to what to do with changes that actually
depend on other changes.

Cheers,
Miguel

  reply	other threads:[~2018-10-03 12:34 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02 13:47 [GIT PULL linux-next] Add Compiler Attributes tree Miguel Ojeda
2018-10-02 13:47 ` Miguel Ojeda
2018-10-02 21:10 ` Stephen Rothwell
2018-10-02 21:10   ` Stephen Rothwell
2018-10-02 21:16   ` Nick Desaulniers
2018-10-02 21:16     ` Nick Desaulniers
2018-10-02 22:12     ` Miguel Ojeda
2018-10-02 22:12       ` Miguel Ojeda
2018-10-02 22:36       ` Dominique Martinet
2018-10-02 22:36         ` Dominique Martinet
2018-10-02 23:00         ` Stephen Rothwell
2018-10-02 23:00           ` Stephen Rothwell
2018-10-03 12:34           ` Miguel Ojeda [this message]
2018-10-03 12:34             ` Miguel Ojeda
2018-10-03 13:00             ` Steven Rostedt
2018-10-03 13:00               ` Steven Rostedt
2018-10-03 12:14         ` Miguel Ojeda
2018-10-03 12:14           ` Miguel Ojeda
2018-10-03 12:30           ` Steven Rostedt
2018-10-03 12:30             ` Steven Rostedt
2018-10-02 23:24       ` Theodore Y. Ts'o
2018-10-02 23:24         ` Theodore Y. Ts'o
2018-10-03 11:54         ` Miguel Ojeda
2018-10-03 11:54           ` Miguel Ojeda
2018-10-03 15:33           ` Theodore Y. Ts'o
2018-10-03 15:33             ` Theodore Y. Ts'o
2018-10-03 21:23             ` Miguel Ojeda
2018-10-03 21:23               ` Miguel Ojeda
2018-10-03 21:41               ` Miguel Ojeda
2018-10-03 21:41                 ` Miguel Ojeda
2018-10-04  5:01                 ` Theodore Y. Ts'o
2018-10-04  5:01                   ` Theodore Y. Ts'o
2018-10-04  9:06                   ` Miguel Ojeda
2018-10-04  9:06                     ` Miguel Ojeda
2018-10-02 22:04   ` Miguel Ojeda
2018-10-02 22:04     ` Miguel Ojeda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANiq72nLLhTf3AsXqLkPmK6TV_g7E3tML9XaM_zE45dM7XPn-A@mail.gmail.com \
    --to=miguel.ojeda.sandonis@gmail.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=arnd@arndb.de \
    --cc=aryabinin@virtuozzo.com \
    --cc=asmadeus@codewreck.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dwmw2@infradead.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=joe@perches.com \
    --cc=keescook@chromium.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-sparse@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=mingo@kernel.org \
    --cc=msebor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=olof@lxom.net \
    --cc=paul.burton@mips.com \
    --cc=paullawrence@google.com \
    --cc=pombredanne@nexb.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=sandipan@linux.vnet.ibm.com \
    --cc=sfr@canb.auug.org.au \
    --cc=sparse@chrisli.org \
    --cc=stefan@agner.ch \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=w@1wt.eu \
    --cc=will.deacon@arm.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.