From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by dpdk.org (Postfix) with ESMTP id 30783558B for ; Sun, 20 Nov 2016 05:17:18 +0100 (CET) Received: by mail-vk0-f49.google.com with SMTP id p9so196801316vkd.3 for ; Sat, 19 Nov 2016 20:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WZ9yfQXf/24fa7uiGyvO4jnndouw+60Ag4uoEXY4ywo=; b=qcRQg82O6itgqrONRUBEpafx2Izz8LWhyTRGrENCtLX16sSz0DnPRuJaB+3cGUu5Fq /gWZU7z5UPStzhj4D+cIEgkHjbfsNo4lleTbd2BKiD6faBHHx0jI3Lisldm6xTy21iWX vFXq/WOlYZEgF7r0jCHrEgrqoo3SonA2yTcRbhNXN3gjSTTC7GzO0aD3pyZ7dTxpJjU6 nsmMbUr+VQey7nqi0RJ+irZ9vky3uqPtR5tG1jbwiscS3Nx+6Kj9l1VWb7wWVoILS3TP HHOLSepVFVOBwhbJIXeKrxcoanOpUw1ZlrFkEFsVJvIIwAy3rQoDm97ZaFNLWDSulqvb 5DSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WZ9yfQXf/24fa7uiGyvO4jnndouw+60Ag4uoEXY4ywo=; b=NCVHZbv9uE3n9E0sJjiSh77cFXAdUoQikHFbya8IA9atXgUj/LtMohjHUf6Up5ap0V RFjnK8Pev072EWlbdjBYdX7A6DPV/mU7e0xNsixnvVRyY0954CE9X1Nz7We65KSwhQem wZMCr5+IZUm7iucHlpWwatjKN1PQfYzWiXvez+JWGgS3whQWxKB+DnE/KTprQnZO5tNj HHsj+xQwcdWCKPQpotdUgdhG5JibX8oJY+Rsp05i3HYPW1K6CukaMuIV/GXGoXd6fVJb TI4NyrF6hShiAnkMutnQQxJUzwK0tlzBErCWJioDhX9+nJ5QjBXtys9KwbVuccbxdNU/ PMYQ== X-Gm-Message-State: AKaTC01ZbcMx4v5rrjjwnVFcONuF9oqyHGVspZ7rkdTKM/pkvjYb+FhxpYDdbnUhyMYKGLQKWZXE82X7L3xa8g== X-Received: by 10.31.214.65 with SMTP id n62mr3675430vkg.127.1479615437564; Sat, 19 Nov 2016 20:17:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.82.202 with HTTP; Sat, 19 Nov 2016 20:17:16 -0800 (PST) In-Reply-To: <20161118190604.GA8335@localhost.localdomain> References: <20161118161025.GC29049@hmsreliant.think-freely.org> <20161118190604.GA8335@localhost.localdomain> From: Stephen Hemminger Date: Sat, 19 Nov 2016 20:17:16 -0800 Message-ID: To: Jerin Jacob Cc: Neil Horman , "Mcnamara, John" , "dev@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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: Sun, 20 Nov 2016 04:17:18 -0000 why aren't some patches as marked trivial and accepted right away. On Fri, Nov 18, 2016 at 11:06 AM, Jerin Jacob < jerin.jacob@caviumnetworks.com> wrote: > On Fri, Nov 18, 2016 at 01:09:35PM -0500, Neil Horman wrote: > > On Thu, Nov 17, 2016 at 09:20:50AM +0000, Mcnamara, John wrote: > > > Repost from the moving at dpdk.org mailing list to get a wider > audience. > > > Original thread: http://dpdk.org/ml/archives/ > moving/2016-November/000059.html > > > > > > > > > Hi, > > > > > > I'd like to propose a change to the DPDK committer model. Currently we > have one committer for the master branch of the DPDK project. > > > > > > One committer to master represents a single point of failure and at > times can be inefficient. There is also no agreed cover for times when the > committer is unavailable such as vacation, public holidays, etc. I propose > that we change to a multi-committer model for the DPDK project. We should > have three committers for each release that can commit changes to the > master branch. > > > > > > There are a number of benefits: > > > > > > 1. Greater capacity to commit patches. > > > 2. No single points of failure - a committer should always be > available if we have three. > > > 3. A more timely committing of patches. More committers should equal a > faster turnaround - ideally, maintainers should also provide feedback on > patches submitted within a 2-3 day period, as much as possible, to > facilitate this. > > > 4. It follows best practice in creating a successful multi-vendor > community - to achieve this we must ensure there is a level playing field > for all participants, no single person should be required to make all of > the decisions on patches to be included in the release. > > > > > > Having multiple committers will require some degree of co-ordination > but there are a number of other communities successfully following this > model such as Apache, OVS, FD.io, OpenStack etc. so the approach is > workable. > > > > > > John > > > > I agree that the problems you are attempting to address exist and are > > worth finding a solution for. That said, I don't think the solution you > > are proposing is the ideal, or complete fix for any of the issues being > > addressed. > > > > If I may, I'd like to ennumerate the issues I think you are trying to > > address based on your comments above, then make a counter-proposal for a > > solution: > > > > Problems to address: > > > > 1) high-availability - There is a desire to make sure that, when patches > > are proposed, they are integrated in a timely fashion. > > > > 2) high-throughput - DPDK has a large volume of patches, more than one > > person can normally integrate. There is a desire to shard that work such > > that it is handled by multiple individuals > > > > 3) Multi-Vendor fairness - There is a desire for multiple vendors to feel > > as though the project tree maintainer isn't biased toward any individual > > vendor. > > > > To solve these I would propose the following solution (which is simmilar > > to, but not quite identical, to yours). > > > > 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. 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. 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. Thomas in turn should by and large, > > only be integrating pull requests. This should address our high- > > throughput issue, in that it will allow multiple maintainers to share the > > workload, and integration should be relatively easy. > > +1 > > > > > 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 > > > > > Regards > > Neil > > > > >