Re: [ANNOUNCE] Shared pull requests (was Re: Workflow for i40iw patch submissions)

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 5224 bytes --]

On Tue, Sep 26, 2017 at 08:13:49AM +0300, Leon Romanovsky wrote:
> On Mon, Sep 25, 2017 at 10:31:47PM -0400, Doug Ledford wrote:
> > On 9/25/2017 11:57 AM, Leon Romanovsky wrote:
> > > On Mon, Sep 25, 2017 at 10:53:01AM -0400, Doug Ledford wrote:
> > >> On 9/24/2017 11:59 PM, Leon Romanovsky wrote:
> > >>> On Sat, Sep 23, 2017 at 11:03:25AM -0400, Doug Ledford wrote:
> > >>>
> > >>> <...>
> > >>>
> > >>>>
> > >>>> I want any shared pull requests to be based on nothing newer than an
> > >>>> rc2 kernel.  I branch my for-next branch at rc2, so if your pull
> > >>>> request is on something later it will pollute my main for-next branch
> > >>>> to merge it.  I plan to merge my own -rc pull requests after rc2 into
> > >>>> my for-next branch, so you won't be missing code that goes into later
> > >>>> rcs if you base your work on my for-next branch, so that's a second
> > >>>> alternative starting point for your shared pull requests should you
> > >>>> need it.
> > >>>
> > >>> From our experience, it is not feasible to demand shared pull
> > >>> requests on "newer than an rc2 kernel".
> > >>
> > >> I said "nothing newer than an rc2 kernel".  Did you mean to leave out
> > >> the nothing?
> > >
> > > Most probably I translated it incorrectly. I wanted to say that all
> > > shared pull requests will be -rc2, -rc3, e.t.c. and probably will never
> > > be -rc1. Did you mean the same?
> > >
> > >>
> > >>> The magic of shared pull request
> > >>> is in the fact that it is based on the same origin for both trees.
> > >>
> > >> Correct.  So, for instance, I'm opening up my for-next area today and it
> > >> will be based on a clean v4.14-rc2.  What I'm then asking for is that
> > >> subsequent driver shared pull requests be based on a v4.14-rc2 tree.
> > >> Your last shared pull request was mostly OK, but it was based on a
> > >> v4.13-rc4 kernel and so it would have simultaneously brought in your
> > >> patches and also all the changes between 4.13-rc2 and 4.13-rc4.
> > >
> > > Why is it "undesired behavior"? Anyhow git request-pull to Linus will
> > > filter all patches which already exist in Linus's tree and you will get
> > > merge of -rc fixes for free in your for-next.
> >
> > You obviously have not been paying attention when Linus yells at me.
>
> I do, but probably we are understanding Linus's responses differently.
>
> You probably mean the conversation after that pull request.
>  * First round of RC fixes for 4.13
>    https://marc.info/?l=linux-rdma&m=150039306716272&w=2
>
> He started to complain about empty merge commit with v4.13-rc1, and continued with explanations
> about difference between back and forward merges. From my point of view, my intention to base
> shared pull request on latest -rcX is exactly forward (good) merge, because it ensures that
> all our future submissions for net/net-next/rdma-rc/rdma-next are completely in sync and
> ready to go.

And if we are talking about back-forward merges, the following merge is
a back one and it was mentioned by Linus as a bad type of merge which
should be avoided:
 * Merge tag 'v4.14-rc2' into k.o/for-next
   https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git/commit/?h=k.o/for-next&id=0d9c2ff1c9f7f8b339fc42ac9763b28c71f1c115

Because your previous for-next was fully merged and new one was opened after
-rc2 and your initial pull request with fixes was accepted during in -rc1 too,
you was supposed simply reset your for-next to v4.14-rc2 tag
git reset --hard v4.14-rc2) as a starting point of for-next.

Thanks

>
> > This is something he specifically does *not* want, and if you send me a
> > shared pull request that is based on, say, -rc4, then I can't merge it
> > into my for-next branch and instead of I have to carry a separate branch
> > and send a separate pull request just for that branch.
>
> I don't think so, but we can probably catch Linus at KS next month and
> ask him directly.
>
> >
> > The reason is that Linus wants to be able to pull up gitk on my pull
> > request and see the changes I am submitting for easy review.  If I merge
> > a shared pull request that also includes an update to the -rc level of
> > my tree, then all those -rc patches get mixed into the gitk ordering and
> > it makes it hard for Linus to find just the patches he wants.  So, this
> > is a Linus issue, not so much my issue.  If he didn't care, I wouldn't
> > either, but this is the way it is.
> >
>
> I don't know how gitk presents git history, but the following command
> "git log --graph --no-merges -- drivers/infiniband include/rdma/ include/uapi/rdma" works like
> a charm and presents only RDMA related commits.
>
> Other replies from Linus about late submission, compiler warnings, tree-wide changes,
> request to separate pull requests, fix with strange name ("Add ...") are completely unrelated.
>
> I read upto 19 Mar 2016, in that pull request Linus explained to us how we should create shared pull request.
> Everything before is not relevant for shared pull requests.
>
> Thanks
>
> >
> > --
> > Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >     GPG Key ID: B826A3330E572FDD
> >     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD
> >
>
>
>



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]