From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by dpdk.org (Postfix) with ESMTP id 620267CB6 for ; Wed, 13 Sep 2017 09:58:57 +0200 (CEST) Received: by mail-wm0-f53.google.com with SMTP id i189so10606800wmf.1 for ; Wed, 13 Sep 2017 00:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=gifTyR054tDUmSK2Fx0dg8dozX7tWoHNp7kAf2fthrI=; b=eXVG5zPx3EyPBStXhRDgRYRimw9HUoYyYEKJbuDK7s9rgP4V+9QhmDIiwXpsif3T4i znTR8BaH52cDtf4r/o00+wRxrcfmVGNSVBrPz4CPJdVfTH0WaGOXJrSbj/wKo3Gxxia8 9jVLIzbplnfwIb8XH/hwcP251DJA6o97frhxERIsO82+iKqqjEQTx9iCxOjrav3xyIMh pZoQTJXSi4nqmM98AtUy9L8Fw7b8O/NczEVTdKa8QYsLOk0bZvUcsPxfseCkcpWIhLwi jSDfiovwcP6Sx1B6H6ba8R2geab/rVinf4o9D5TyPR/QNRxw6pK80a563Hjdq9cqIEHU 34Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=gifTyR054tDUmSK2Fx0dg8dozX7tWoHNp7kAf2fthrI=; b=gSWjHmuVxu3O96T6O/qenyaXmkwD00PSrvxi0JezIpXbzJsWXbfUWrexvW+3ZmdVJ/ RwvEEhnP6oXEEP4arnKKNLy0WbXOOg9eR/4sj66NvQeDIMhnJwSnR3Sz4C7bXpYIonwV Y3AVF/3UvIZgd83d7qMe1wuesv1D2IUKmdKcbghDGzhT962axvPYIJBEY4Ewjj7CLI1g Xtn5BPW+yokv7WjILzMx3sY5i5iYNcExblgNDQyqXPLBifI9gjwU48goIGIpUXzb0473 qhDIWlAkzOd+Mjj1aZVYpJS17bUx0DfZBQpPe/cyZeNQC8H6qOxHq1MeXKvWdgJpACp7 zSgQ== X-Gm-Message-State: AHPjjUiHTOIZvuPqv2sSaC4pSMoUsQ6+56cjuI58hnr7k7yMgKdCE3Z/ jxki2odXeKQFqYn0wbs= X-Google-Smtp-Source: AOwi7QBBWdXJ4t4T+wl4laSETRnAfApH4XIU8/gsq288fMR+xQtvtv06kiV4x1jPV/WYqVeDJZ4FPg== X-Received: by 10.28.132.73 with SMTP id g70mr1588430wmd.33.1505289535514; Wed, 13 Sep 2017 00:58:55 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id o9sm7668664wre.68.2017.09.13.00.58.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 00:58:54 -0700 (PDT) Date: Wed, 13 Sep 2017 09:58:45 +0200 From: Adrien Mazarguil To: Bruce Richardson Cc: Thomas Monjalon , ferruh.yigit@intel.com, stephen@networkplumber.org, dev@dpdk.org Message-ID: <20170913075845.GR2481@6wind.com> References: <2737351.pD9poAUtZC@xps> <20170912083207.GC40060@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170912083207.GC40060@bricha3-MOBL3.ger.corp.intel.com> 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 07:58:57 -0000 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? -- Adrien Mazarguil 6WIND