From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <keith.wiles@intel.com> Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 03AA6199A9; Thu, 14 Sep 2017 14:50:40 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 05:50:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,392,1500966000"; d="scan'208";a="1014399343" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 14 Sep 2017 05:50:39 -0700 Received: from fmsmsx102.amr.corp.intel.com ([169.254.10.194]) by fmsmsx104.amr.corp.intel.com ([169.254.3.185]) with mapi id 14.03.0319.002; Thu, 14 Sep 2017 05:50:38 -0700 From: "Wiles, Keith" <keith.wiles@intel.com> To: Thomas Monjalon <thomas@monjalon.net> CC: "Richardson, Bruce" <bruce.richardson@intel.com>, Stephen Hemminger <stephen@networkplumber.org>, Adrien Mazarguil <adrien.mazarguil@6wind.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "techboard@dpdk.org" <techboard@dpdk.org> Thread-Topic: [dpdk-dev] git trees organization Thread-Index: AQHTK0nqUAd7LDiq8UmGCnn56tQPIaKxYgGAgAGJAoCAAD1ugIAADQqAgAAPkQCAABn/AIAAwR+AgABjyYCAAAuUAIAAA/0AgAA7XoA= Date: Thu, 14 Sep 2017 12:50:38 +0000 Message-ID: <C2414B0E-BB92-47D1-8C56-0AC135DA6EB1@intel.com> References: <2737351.pD9poAUtZC@xps> <5858182.HmkBWfGZLK@xps> <20170914090349.GA50056@bricha3-MOBL3.ger.corp.intel.com> <5035401.hoKbokARAT@xps> In-Reply-To: <5035401.hoKbokARAT@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.70.50] Content-Type: text/plain; charset="us-ascii" Content-ID: <759CB47CF527B242B41E292253E58DE6@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 14 Sep 2017 12:50:41 -0000 > On Sep 14, 2017, at 4:18 AM, Thomas Monjalon <thomas@monjalon.net> wrote: >=20 > 14/09/2017 11:03, Bruce Richardson: >> On Thu, Sep 14, 2017 at 10:22:23AM +0200, Thomas Monjalon wrote: >>> 14/09/2017 04:25, Stephen Hemminger: >>>> Bisecting a tree with lots of subtree merges is terrible. That is why = Linus >>>> rebases and doesn't directly take linux-next >>>=20 >>> I agree, bisecting with subtree merges is not pleasant at all. >>> That's why I chose the rebase method until now. >>>=20 >>> Adrien mentioned some drawbacks with the rebase method. >>> Ferruh mentioned some drawbacks and some advantages of rebase. >>> Stephen mentioned another advantage of rebase. >>> Such decisions are really difficult. >>> One thing is sure: there will be always someone unhappy, >>> no matter the decision :) >>>=20 >>> When we want to take such decision or re-consider it, >>> we ask the techboard to vote... >>=20 >> I'm not sure the techboard needs to vote on this, this is an issue for >> the tree maintainers/committers is it not? If you do want techboard >> input on this, I suggest the committers come to an agreement among >> themselves, with community input, and then just look for tech board to >> ratify it. >=20 > No, it is an issue for everybody. > Rebase makes tracking of subtrees difficult for developpers. > Merge makes reading and bisecting difficult for developpers. > We cannot have an agreement in the community because both arguments > are valid. It seems to me the lesser of the two evils is rebase, but I have not used b= isect much. I would think we pick rebase and see how it goes as I know merg= ing can be a bit of a problem. We can always pick merge later if we find a = specific issue we need to fix or bisect. I know it is not ideal, but we nee= d to pick one and move on. >=20 > I add that merge can slow down subtree integration if a change is needed. > From my point of view, it is OK as it is currently. >=20 > It is maybe as difficult as choosing between vim and emacs ;) > (although it seems crazy to use emacs) What Emacs does everything for you even writes your code for you, that is w= hy I use vim and visual studio code to write my programs just so I feel use= ful and not replaced by Emacs :-) Regards, Keith