From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 83DCA7CB6 for ; Wed, 13 Sep 2017 13:38:39 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga105.jf.intel.com with ESMTP; 13 Sep 2017 04:38:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,387,1500966000"; d="scan'208";a="1171815860" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.57]) ([10.237.220.57]) by orsmga001.jf.intel.com with ESMTP; 13 Sep 2017 04:38:37 -0700 To: Adrien Mazarguil , Bruce Richardson Cc: Thomas Monjalon , stephen@networkplumber.org, dev@dpdk.org References: <2737351.pD9poAUtZC@xps> <20170912083207.GC40060@bricha3-MOBL3.ger.corp.intel.com> <20170913075845.GR2481@6wind.com> From: Ferruh Yigit Message-ID: Date: Wed, 13 Sep 2017 12:38:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170913075845.GR2481@6wind.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] git trees organization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 11:38:41 -0000 On 9/13/2017 8:58 AM, Adrien Mazarguil wrote: > Hi, > > On Tue, Sep 12, 2017 at 09:32:07AM +0100, Bruce Richardson wrote: >> On Tue, Sep 12, 2017 at 12:03:30AM +0200, Thomas Monjalon wrote: >>> Hi all, >>> >>> As you know I am currently the only maintainer of the master tree. >>> It is very convenient because I need to synchronize with others >>> only when pulling "next-*" trees. >>> But the drawback is that I should be available very often to >>> avoid stalled patches waiting in patchwork backlog. >>> >>> I feel it is the good time to move to a slightly different organization. >>> I am working closely with Ferruh Yigit for almost one year, as next-net >>> maintainer, and I think it would be very efficient to delegate him some >>> work for the master tree. >> >> I think Ferruh has been doing an excellent job on the net tree, and >> would be an excellent candidate to help with the workload on the master >> tree. >> >>> I mean that I would use the patchwork delegation to explicitly divide >>> the workload given our different experiences. >>> Ferruh, do you agree taking this new responsibility? >>> >>> At the same time, we can think how to add more git sub-trees: >> >> In principle, I'm in favour, but I think that the subtrees of the master >> tree should be at a fairly coarse granularity, and not be too many of >> them. The more subtrees, the more likely we are to have issues with >> patchsets needing to be split across trees, or having to take bits from >> multiple trees in order to test if everything is working. > > > About that, how about we start allowing true merge commits instead of > rebasing (rewriting history) in order to ease things for maintainers? > > This approach makes pull requests show up as a merge commits that contain > the (ideally trivial) changes needed to resolve any conflicts; this has the > following benefits: > > - The work done by a maintainer during that merge is tracked, not silently > ignored or lost. The merge commit itself is signed-off by its author. > > - This allows tracing mistakes or bugs to the conflict resolution itself. > > - Upstream can reject pull requests on the basis that merging it is not > trivial enough (i.e. downstream must merge upstream changes first). > > - Sub-trees can merge among themselves in case they need features that > encompass several trees, not necessarily always against the master > tree. Everything is tracked. > > - Maintainers do not ever modify the commits they get from other trees, > which keep their SHAs unmodified as part of the history. A given commit ID > is truly unique among all trees (back-port trees remain the only exception > since commits are cherry-picked). > > - It shifts the entire responsibility to the maintainers of sub-trees. > > The only downside is that commits have several parents, history becomes a > graph that developers need to get used to (some might call it a mess), > however that's probably not an issue for those already used to Linux kernel > development and other large projects. > > I know this was already discussed in the past, however I think adding more > sub-trees will make rebasing too complex otherwise> > Thoughts? > Using git merge looks more proper git usage, but I have one question / concern: For next-net, sometimes there are dependent patches in main tree, and what I am doing is rebasing sub-tree on top of latest main tree. When switched to merge method, how dependent patches can be get into the sub-tree? Merge from main tree to sub-tree? Won't this bidirectional merging confusing? And following are notes from my current experience: - Having re-writable history gives some flexibility to sub-trees. Possible to update commit logs and amend patches even after pushed. - It is hard to confirm pulled commits in main tree, I guess merge commit will make this easier. - To track main tree, continuously rebasing and continuously re-writing history, I am doing this almost daily, this may be hard for people working on top of next-net. - Conflict resolving done by sub-trees during rebase, instead of done by main tree during merge. So this may be more distributed effort. - Rebasing gives more straight forward history in main repo, merge commits looks more confusing, although I would expect it won't be as complex as Linux tree, so may not be a problem. Thanks, ferruh