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. 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
