From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 8A1F77CB6 for ; Wed, 13 Sep 2017 14:25:29 +0200 (CEST) Received: by mail-wm0-f46.google.com with SMTP id a137so7692321wma.0 for ; Wed, 13 Sep 2017 05:25:29 -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=0IjCjYViSxLHiGFgTHp6yKrCAicX2ngxM1v/XK3IGh8=; b=z7GED1vBfG8sMRCM5dIdFozJTGgIEH0dSo7/LAJS32URjzZf5bc5HJLDZxcxQZ/QXK YzjdY9rZSi4GIOrDDCJlsYBwjCDxNMxFxdVjKEOSByrgh4huWVkR8fydKSaKTBJNWRoM 0csHNHHIEI6q7+r+krpiurn9wQEsSqdi9EWcnECIujI69NYtIrqNjPE5IUXyIIPFbf0K RrYVag29LUCInTaj8VXAtqSt6H5FQYCuB0FnDk9ryV+ClS24SfQsRqx3+7PP1MNbHLGc oDUV1FfnoeyV7HyJmvMyYUI+46MrFF0GboHceHnph0MDkrdI7vZAgRplQ8vVGvrvxgC3 X7sQ== 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=0IjCjYViSxLHiGFgTHp6yKrCAicX2ngxM1v/XK3IGh8=; b=MBB95WDO9lrm5fA7ZtBHsQWR35X6OOl/fsJnMZ9cSV3+z3aTP//0Dccz9Rukd+eWW/ CyKSady14M+6VO3Y1vz0ZQW80rFhgPo6hCVx1r3Wg7V8B9PoecFXY3lpMqf6UCTPnlvF qk3O0A0igpnD85/OSswzLEc5Mr4/7DhzVOHF4IFt38Q8qSnQvlelp1wPbjKpyeWgomCz BRjjpSVYHa2djlIMulbQfkHD+5ODHRlvg9Rpusfna8D3xlp3T3bdxMlwaNkzL85VjzBC ty180QbKGoYlNV6+gdVD0DDu8AbFbusEqdUhX+tk6JHtEOHaZsDWr0Y2b6zu+VGCyt/u jznA== X-Gm-Message-State: AHPjjUiF34LUksXuiln/qgCXL7UwM/fKJoktsjX4M9ebrmODUzs6qM5G MOfbUXD8ZX12Ka7I9WJ2hmMyLw== X-Google-Smtp-Source: AOwi7QA26C6fhM9Trq66WQsjFHY5OdjqsugHXQHWw92D1vrmTIgm75IUl2WBaXno+zAyQ0qaYDETtg== X-Received: by 10.28.191.68 with SMTP id p65mr2161729wmf.137.1505305529059; Wed, 13 Sep 2017 05:25:29 -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 h128sm944217wmf.9.2017.09.13.05.25.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 05:25:28 -0700 (PDT) Date: Wed, 13 Sep 2017 14:25:17 +0200 From: Adrien Mazarguil To: Ferruh Yigit Cc: Bruce Richardson , Thomas Monjalon , stephen@networkplumber.org, dev@dpdk.org Message-ID: <20170913122517.GZ2481@6wind.com> References: <2737351.pD9poAUtZC@xps> <20170912083207.GC40060@bricha3-MOBL3.ger.corp.intel.com> <20170913075845.GR2481@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 12:25:29 -0000 On Wed, Sep 13, 2017 at 12:38:37PM +0100, Ferruh Yigit wrote: > On 9/13/2017 8:58 AM, Adrien Mazarguil wrote: > > 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? > > > > Using git merge looks more proper git usage, but I have one question / > concern: > > For next-net, sometimes there are dependent patches in main tree, and > what I am doing is rebasing sub-tree on top of latest main tree. > > When switched to merge method, how dependent patches can be get into the > sub-tree? Merge from main tree to sub-tree? Yes, that's the idea. On the other hand, as a maintainer, you are not responsible for the contents of what's merged from other official trees. Commits are taken as they are, this implies trust between tree maintainers. > Won't this bidirectional merging confusing? Probably at first, this certainly needs some getting used to. We can attempt to avoid such merges as much as possible with proper coordination. Avoiding them is likely not possible though if we want to keep history intact. > And following are notes from my current experience: > > - Having re-writable history gives some flexibility to sub-trees. > Possible to update commit logs and amend patches even after pushed. This is both a good and a bad thing. Thanks to that, history is currently linear and extremely clean, I think we haven't had a single patch that doesn't compile or a bad merge artifact for a very long time. On the other hand, if you look at the effort required to maintain a single sub-tree that way, it likely becomes exponential for several. All of them need to constantly rebase their stuff, with conflicts to address. The more people, the more mistakes and so on. Once part of an official tree, a commit cannot be amended anymore, it's too late; revert commits will be more common. We need to accept this first. > - It is hard to confirm pulled commits in main tree, I guess merge > commit will make this easier. > > - To track main tree, continuously rebasing and continuously re-writing > history, I am doing this almost daily, this may be hard for people > working on top of next-net. Yes that's one of the "bad" things with the current approach. Consider automatic non-regression testing against disappearing commit IDs. Tracking their status is difficult when history is changing. For instance we usually add local tags to track CI successes/failures. All of them now point to nonexistent commits. > - Conflict resolving done by sub-trees during rebase, instead of done by > main tree during merge. So this may be more distributed effort. It's not too different actually. With merge you can reject PRs on the basis that there are too many conflicts to take care of, not unlike a request for rebase. On the plus side if you make any changes yourself in order to solve them, they are made part of the merge commit, not in the original commits which remain unmodified. > - Rebasing gives more straight forward history in main repo, merge > commits looks more confusing, although I would expect it won't be as > complex as Linux tree, so may not be a problem. Right, that's the main drawback. I think there's no way to know the impact unless we attempt it as an experiment. -- Adrien Mazarguil 6WIND