On 11/23/2016 3:33 PM, Neil Horman wrote: > On Wed, Nov 23, 2016 at 02:01:44PM +0000, Ferruh Yigit wrote: >> On 11/23/2016 1:48 PM, Neil Horman wrote: >>> On Tue, Nov 22, 2016 at 08:56:23PM +0000, Ferruh Yigit wrote: >>>> On 11/22/2016 7:52 PM, Neil Horman wrote: >>>>> On Mon, Nov 21, 2016 at 09:52:41AM +0100, Thomas Monjalon wrote: >>>>>> 2016-11-18 13:09, Neil Horman: >>>>>>> A) Further promote subtree maintainership. This was a conversation >>>>>>> that I >>>>>>> proposed some time ago, but my proposed granularity was discarded in >>>>>>> favor >>>>>>> of something that hasn't worked as well (in my opinion). That is to >>>>>>> say a >>>>>>> few driver pmds (i40e and fm10k come to mind) have their own tree that >>>>>>> send pull requests to Thomas. >>>>>> >>>>>> Yes we tried this fine granularity and stated that it was not working >>>>>> well. >>>>>> We are now using the bigger granularity that you describe below. >>>>>> >>>>> Ok, thats good, but that must be _very_ new. Looking at your git tree, I >>>>> see no >>>>> merge commits. How are you pulling from those subtrees? >>>> >>>> next-net tree is active for last three releases. >>>> >>> What!? What is the purpose of holding patches in a subtree for multiple >>> releases? >> >> :) Of course not holding them in the sub-tree. >> > Ok, glad that we're on the same page. > >> Briefly, process is: >> - sub-tree gets patches during merge window >> - sub-tree first merged into main tree in -rc1 and later in -r2 >> >> next-net tree is actively in use for last three releases, and driver/net >> patches delegated to this tree. You can see different commiters in main >> tree. >> >>> If a given changeset isn't ready for merge to Thomas tree the people >>> working on it should clone the subtree to some place they can all >>> collaborate on >>> it. Once it goes into a subtree there needs to be a defined workflow to >>> get it >>> into the canonical tree that Thomas maintains on a regular, short time >>> frame. >>> to do less is to confuse the process for everyone involved, and slow people >>> down, rather than accelerate their work. >>> >>>> I guess following is the first commit to the sub-tree: >>>> http://dpdk.org/ml/archives/dev/2016-February/032580.html >>>> >>>> sub-trees rebase on top of main tree regularly, that is why there is no >>>> merge commit. >>>> >>> I'm not asking about merge commits in the sub-tree, I'm asking about merge >>> commits in thomas's tree. >> >> Same, talking about Thomas' tree. >> >>> There should be a merge commit every time he pulls >>> from a sub-tree (unless its a fast-forward I think, but with multiple >>> subtrees >>> and commits going to thomas directly, that should never really happen). >> >> That is what happening. Since sub-tree's rebase on top of main tree, >> when Thomas merges, it is just plain fast-forward. So it is allowed to >> re-write to history in sub-trees. >> > ok, I see what you're saying here, but I still don't see how this results in > no > merge commits. From what I can see we have at least 4 subtrees (next-crypto, > next-net, next-eventdev, next-virtio). If you rebase all on lastest version > of > thomas's tree, and then they all make changes and send a pull request, the > first > to be merged will, by definition be a fast forward. The remaining three > however, cannot be, because the prior merge has advanced the HEAD commit in > Thomas's tree such that its divergent from the subsequent tree to be merged. > So there > should be some merge commits in Thomas's tree.
This is simple indeed, all can do fast-forward, because all sub-trees touch to different files. Currently: next-net: drivers/net/* [except virtio and vhost] next-crypto: drivers/crypto/* next-virtio: drivers/net/virtio/*, drivers/net/vhost/* Common files are in main tree, when all rebased on top of it, they all can be merged as fast-forward. > > The only way I see around that, is if the merges are serialized (i.e. if you > provide an order to the subtrees and each subtree rebases from thomas prior to > applying its patches, then merges back to thomas's tree). Thats rather > defeating > of the purpose of parallel trees though. You can all rebase, but then you > operate independently of each other. Thats how we realize a speedup here > > > Neil >
