From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id C88C4938A for ; Thu, 22 Oct 2015 14:01:00 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 22 Oct 2015 05:01:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,181,1444719600"; d="scan'208";a="800123429" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga001.jf.intel.com with ESMTP; 22 Oct 2015 05:00:59 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 22 Oct 2015 05:00:58 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.253]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.47]) with mapi id 14.03.0248.002; Thu, 22 Oct 2015 20:00:57 +0800 From: "Lu, Wenzhuo" To: Thomas Monjalon Thread-Topic: volunteer to be the maintainer of driver/net/intel sub-tree Thread-Index: AdEMcePuHEOjNampS2allCyTjWwUFP//2kiA//9HkDA= Date: Thu, 22 Oct 2015 12:00:56 +0000 Message-ID: <6A0DE07E22DDAD4C9103DF62FEBC0909020A1C59@shsmsx102.ccr.corp.intel.com> References: <6A0DE07E22DDAD4C9103DF62FEBC0909020A1938@shsmsx102.ccr.corp.intel.com> <2241359.mdZUFIHDJv@xps13> In-Reply-To: <2241359.mdZUFIHDJv@xps13> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiJkODE0MjM1Zi04MmFhLTQ3NTctODNmMi00MmU1NmVhZWExMTMiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfUFVCTElDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjQuMTAuMTkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiXC84KzNoNUdubWtHYVllbWd5VWNFbkVSeG01TUNYNDNoVHVBSGdaTWttSGc9In0= x-inteldataclassification: CTP_PUBLIC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] volunteer to be the maintainer of driver/net/intel sub-tree X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 12:01:01 -0000 Hi Thomas, > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Thursday, October 22, 2015 4:17 PM > To: Lu, Wenzhuo > Cc: dev@dpdk.org; Zhang, Helin; Richardson, Bruce > Subject: Re: volunteer to be the maintainer of driver/net/intel sub-tree >=20 > Hi Wenzhuo, >=20 > 2015-10-22 02:49, Lu, Wenzhuo: > > Hi all, > > Following the discussion of DPDK user space and the maintenance of > development sub-trees, I'd like to volunteer myself to be the maintainer = of > sub-tree driver/net/intel. It includes all the PMD of Intel NICs. And Hel= in can > be my backup. >=20 > Thanks for proposing. > You are already doing part of the work being maintainer of e1000, and Hel= in > for ixgbe and i40e. >=20 > > I suggest we create a new directory to move the driver/net/e1000, > driver/net/fm10k... to it. And we can also create directories for other > vendors just like the kernel driver do. >=20 > We don't need to move files to be able to manage them in a sub-tree. > For the day to day tasks, it's better to limit directory depth. > And think about what happened with Broadcom and Qlogic, we are not > going to move files when Intel will buy the NIC xyz. > Generally speaking, it's better to keep company names outside of technica= l > things. >=20 I think you're reasonable. I thought adding a directory may make thing's si= mple, but the reality is it may introduce something that's out of our control. :) But a single directory also has its benefit, it can easily let us know all = the things in the directory is maintained by a or a group of owners. I think the key i= s how to let the developers know what happens. If something can explain itself, we n= eed not clarify it. Agree we'd better not adding the company name. But I think it's= still worth thinking about how to make things more clear. Honestly, I don't have any pr= oposal now. Maybe we have to come out a doc at last. :) > > Additionally, as we observed, some patch sets will not only change the = files > in drivers/net, but also some files in lib/librte_ether, doc, app, exampl= es... > Only being drivers/net/intel maintainer cannot work for these patch sets, > especially for the new features. Applying partial feature patch set is no= t ideal. > Ideally we need a maintainer to drive the RTE_ETHER discussion. Maybe > Bruce can be a top-level maintainer. So, he can help when we face this > scenario. >=20 > A sub-tree is not restricted to some directories. It must manage an exper= tise > zone, a technical domain, an area of interest, choose your words ;) >=20 > Today we have no working sub-tree. So we should start splitting areas in > some large grain and make it work. Then we can split more with a top down > approach. > So I think we should first create the subtree for networking drivers and = wait > a little before having a subtree for Intel NICs. >=20 > Do you agree? Honestly, I cannot tell which is better that we begin with a big area or a = small area. But I agree we should have something working first. It can become a guide . A sub-tree for networking drivers seems to be a good option. If it's not to= o bothering, I'd like to mention again that the concern is the networking drivers are af= finitive with rte_eth.