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 58A853277 for ; Wed, 23 Nov 2016 09:21:44 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP; 23 Nov 2016 00:21:42 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,537,1473145200"; d="scan'208";a="34739368" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga005.fm.intel.com with ESMTP; 23 Nov 2016 00:21:41 -0800 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.91]) by irsmsx105.ger.corp.intel.com ([169.254.7.43]) with mapi id 14.03.0248.002; Wed, 23 Nov 2016 08:21:40 +0000 From: "Mcnamara, John" To: Neil Horman , Thomas Monjalon CC: "dev@dpdk.org" , Jerin Jacob , Stephen Hemminger Thread-Topic: [dpdk-dev] Proposal for a new Committer model Thread-Index: AdJAs7riGyOWXzb1RBWkYul07VgIhwBEzAqAAINsvYAASVOWgAAZpXvw Date: Wed, 23 Nov 2016 08:21:39 +0000 Message-ID: References: <20161118161025.GC29049@hmsreliant.think-freely.org> <1855350.07sWV4iMZa@xps13> <20161122195215.GA4463@hmsreliant.think-freely.org> In-Reply-To: <20161122195215.GA4463@hmsreliant.think-freely.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNmIxNTQ1NzUtN2NmMC00YTQ2LTliY2UtMGU5N2U4NWM5NWMwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6ImF1NGtsaVpYZEJBTVd1dXNVSHh3ajZjRlJhdFU0cnhCVHVcL2hmK25KR3dRPSJ9 x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Proposal for a new Committer model 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: Wed, 23 Nov 2016 08:21:44 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Tuesday, November 22, 2016 7:52 PM > To: Thomas Monjalon > Cc: dev@dpdk.org; Mcnamara, John > Subject: Re: [dpdk-dev] Proposal for a new Committer model >=20 > 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? >=20 Hi Neil, It seems like the weight of consensus in around your proposal for further s= ubtree maintainers and backups. If you don't mind I'll take your text and r= edraft it as a potential section on maintainership for a future Project Cha= rter document. Or at least so that we have a documented maintainship proces= s. =20 > > > 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) Could we define some of the potential subtrees now and look to introduce th= em in the this release cycle? EAL and the Core libs, as suggested by Thomas= , seem like 2 obvious ones. >=20 > > > 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. I'd prefer not to have split dev lists, for now at least. We can reevaluate= that again in a few months though. > > >=20 > > > B) Designate alternates to serve as backups for the maintainer when > > > they are unavailable. This provides high-availablility, and sounds > > > very much like your proposal, but in the interests of clarity, there > > > is still a single maintainer at any one time, it just may change to > > > ensure the continued merging of patches, if the primary maintainer > isn't available. > > > Ideally however, those backup alternates arent needed, because most > > > of the primary maintainers work in merging pull requests, which are > > > done based on the trust of the submaintainer, and done during a very > > > limited window of time. This also partially addreses multi-vendor > > > fairness if your subtree maintainers come from multiple participating > companies. +1 on this apart from the limited merge window (for reasons similar to Thom= as). Should we have a call for volunteers for backup, on master and the sub-tree= s, followed by a simple +1 from community members to endorse them? John