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. 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. > I don't > see any Merge commits in the master branch of his tree, so I'm left wondering > what mechanic is being used to migrate patches from net-next or crypo-next to > his tree. Thomas, can you comment here? > >>> >>> >>>>> We should be sharding that at a much higher >>>>> granularity and using it much more consistently. That is to say, that we >>>>> should have a maintainer for all the ethernet pmds, and another for the >>>>> crypto pmds, another for the core eal layer, another for misc libraries >>>>> that have low patch volumes, etc. >>>> >>>> Yes we could open a tree for EAL and another one for the core libraries. >>>> >>> That could be worthwhile. Lets see how the net and crypto subtrees work out >>> (assuming again that these trees are newly founded) >>> >>> >>>>> Each of those subdivisions should have >>>>> their own list to communicate on, and each should have a tree that >>>>> integrates patches for their own subsystem, and they should on a regular >>>>> cycle send pull requests to Thomas. >>>> >>>> Yes I think it is now a good idea to split the mailing list traffic, >>>> at least for netdev and cryptodev. >>>> >>> Agreed, that serves two purposes, it lowers the volume for people with a >>> specific interest (i.e. its a rudimentary filter), and it avoids confusion >>> between you and the subtree maintainer (that is to say, you don't have to >>> even >>> consider pulling patches that go to the crypo and net lists, you just have >>> to >>> trust that they pull those patches in and send you appropriate pull >>> requests). >> >> I still find single mail list more useful. > Why? If you have interest in all the subsystems of a project, then its a > small > amount of overhead to subscribe to a set of mailing lists and dump them all > to a > single mail folder. If you only have interest in a subset, its much more > difficult to filter them out, given that we have a plethora of prefix tags for > patches to define subsystems that aren't always used consistently. Given that > this thread is here because we've identified the patch volume as a problem, it > seems fragmenting the list is the better solution. > >> Also with current process, after -rc2 release, patches directly merged >> into main tree instead of sub-trees... >> > Thats fine, at that point, if everything works properly, Thomas should only be > getting low volume patch flow for stabilization/bug fixing. If thats not the > case, then perhaps we need to consider doing extra merges from the subtrees > later in the cycle. > > Neil >