From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Ferruh Yigit <ferruh.yigit@intel.com>,
dev@dpdk.org, techboard@dpdk.org
Subject: Re: git trees organization
Date: Thu, 14 Sep 2017 11:18:06 +0200 [thread overview]
Message-ID: <5035401.hoKbokARAT@xps> (raw)
In-Reply-To: <20170914090349.GA50056@bricha3-MOBL3.ger.corp.intel.com>
14/09/2017 11:03, Bruce Richardson:
> On Thu, Sep 14, 2017 at 10:22:23AM +0200, Thomas Monjalon wrote:
> > 14/09/2017 04:25, Stephen Hemminger:
> > > Bisecting a tree with lots of subtree merges is terrible. That is why Linus
> > > rebases and doesn't directly take linux-next
> >
> > I agree, bisecting with subtree merges is not pleasant at all.
> > That's why I chose the rebase method until now.
> >
> > Adrien mentioned some drawbacks with the rebase method.
> > Ferruh mentioned some drawbacks and some advantages of rebase.
> > Stephen mentioned another advantage of rebase.
> > Such decisions are really difficult.
> > One thing is sure: there will be always someone unhappy,
> > no matter the decision :)
> >
> > When we want to take such decision or re-consider it,
> > we ask the techboard to vote...
>
> I'm not sure the techboard needs to vote on this, this is an issue for
> the tree maintainers/committers is it not? If you do want techboard
> input on this, I suggest the committers come to an agreement among
> themselves, with community input, and then just look for tech board to
> ratify it.
No, it is an issue for everybody.
Rebase makes tracking of subtrees difficult for developpers.
Merge makes reading and bisecting difficult for developpers.
We cannot have an agreement in the community because both arguments
are valid.
I add that merge can slow down subtree integration if a change is needed.
>From my point of view, it is OK as it is currently.
It is maybe as difficult as choosing between vim and emacs ;)
(although it seems crazy to use emacs)
next prev parent reply other threads:[~2017-09-14 9:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-11 22:03 git trees organization Thomas Monjalon
2017-09-12 8:32 ` Bruce Richardson
2017-09-12 8:48 ` Thomas Monjalon
2017-09-12 13:01 ` Wiles, Keith
2017-09-12 16:34 ` Ferruh Yigit
2017-09-13 7:58 ` Adrien Mazarguil
2017-09-13 11:38 ` Ferruh Yigit
2017-09-13 12:25 ` Adrien Mazarguil
2017-09-13 13:21 ` Ferruh Yigit
2017-09-13 14:54 ` Adrien Mazarguil
2017-09-14 2:25 ` Stephen Hemminger
2017-09-14 8:22 ` Thomas Monjalon
2017-09-14 9:03 ` Bruce Richardson
2017-09-14 9:18 ` Thomas Monjalon [this message]
2017-09-14 12:50 ` Wiles, Keith
2017-09-14 9:11 ` Nélio Laranjeiro
2017-09-14 17:57 ` Stephen Hemminger
2017-09-12 16:32 ` Ferruh Yigit
2017-09-12 20:20 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5035401.hoKbokARAT@xps \
--to=thomas@monjalon.net \
--cc=adrien.mazarguil@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=stephen@networkplumber.org \
--cc=techboard@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.