2021-01-26 05:17:14

by Christian Brauner

[permalink] [raw]
Subject: Dealing with complex patch series in linux-next

Hey,

After having received another round of acks on the idmapped mounts
series and other fses about to move forward with porting I moved forward
with merging [1] into my for-next branch which is tracked by sfr in
linux-next.
Given the nature of the series I expected there to be a good chunk of
merge conflicts including some non-trivial ones. But there proved to be
too many conflicts or at least a few ones that sfr couldn't handle
without more insight into the series. So after talking to sfr this
morning we decided to drop the tree for today.

Obviously we would like to see this in linux-next and we will likely run
into similar problems should you decide to want to pull this.
I could try and choose a common base with at least one tree (e.g. Al's)
but this will only get rid of some merge conflicts.
I'm sure I could also do an extremely fine-grained split of each patch
in the series though I don't think that's very helpful in this case
either.
I could do a daily rebase onto linux-next which is similar to what
Andrew does for such patch series which get included into linux-next as
a rebased post-next patchbomb (as sfr pointed out to me). The series has
a large xfstest series associated with it so it's at least easily
detectable when the rebase breaks things.
I would prefer to not have to burden someone else with this and rather
deal with the merge conflict resolution myself to make sure that no
wider context is missed. It would also allow me to point out where the
painpoints are if this gets sent for inclusion/is accepted.

So completely independent of whether or not you ultimately decide to
accept or reject the series it might be pretty helpful to know what your
preferred way of dealing with similar series is to make it easier for
you later on.

Christian

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=idmapped_mounts

I know that we have
https://www.kernel.org/doc/html/latest/maintainer/rebasing-and-merging.html
and it touches on stuff like this to some extent in "Merging from
sibling or upstream" trees but it's not clear that this would be
beneficial here or whether it wouldn't just make the changeset harder to
follow.


2021-01-26 12:37:41

by Christian Brauner

[permalink] [raw]
Subject: Re: Dealing with complex patch series in linux-next

On Tue, Jan 26, 2021 at 07:00:30PM +1100, Stephen Rothwell wrote:
> Hi Christian,
>
> On Mon, 25 Jan 2021 10:43:23 +0100 Christian Brauner <[email protected]> wrote:
> >
> > After having received another round of acks on the idmapped mounts
> > series and other fses about to move forward with porting I moved forward
> > with merging [1] into my for-next branch which is tracked by sfr in
> > linux-next.
> > Given the nature of the series I expected there to be a good chunk of
> > merge conflicts including some non-trivial ones. But there proved to be
> > too many conflicts or at least a few ones that sfr couldn't handle
> > without more insight into the series. So after talking to sfr this
> > morning we decided to drop the tree for today.
>
> OK, so tomorrow, I will try merging your tree really early. This will,
> at least, spread the conflict pain out for me (yesterday it hit all at
> once at 4pm and added an hour to my day before I gave up). Lets see
> how that goes.
>
> Unless someone comes up with a better suggestion, of course :-)

I'm happy to help you if you want me to apply it to somewhere specific,
rebase or whatever. I have no problem doing it on a daily basis if that
makes it easier for you.

(Btw, I'm not sure this mail has made it to everyone here. It's
definitely not on lkml (as of now) seemingly because vger is having some
issues.)

Christian

2021-01-26 20:06:37

by Stephen Rothwell

[permalink] [raw]
Subject: Re: Dealing with complex patch series in linux-next

Hi Christian,

On Mon, 25 Jan 2021 10:43:23 +0100 Christian Brauner <[email protected]> wrote:
>
> After having received another round of acks on the idmapped mounts
> series and other fses about to move forward with porting I moved forward
> with merging [1] into my for-next branch which is tracked by sfr in
> linux-next.
> Given the nature of the series I expected there to be a good chunk of
> merge conflicts including some non-trivial ones. But there proved to be
> too many conflicts or at least a few ones that sfr couldn't handle
> without more insight into the series. So after talking to sfr this
> morning we decided to drop the tree for today.

OK, so tomorrow, I will try merging your tree really early. This will,
at least, spread the conflict pain out for me (yesterday it hit all at
once at 4pm and added an hour to my day before I gave up). Lets see
how that goes.

Unless someone comes up with a better suggestion, of course :-)
--
Cheers,
Stephen Rothwell


Attachments:
(No filename) (499.00 B)
OpenPGP digital signature