From: Fengguang Wu <fengguang.wu@intel.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Xiaolong Ye <xiaolong.ye@intel.com>,
git@vger.kernel.org, ying.huang@intel.com, philip.li@intel.com,
julie.du@intel.com,
Linus Torvalds <torvalds@linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Christoph Hellwig <hch@lst.de>, "H. Peter Anvin" <hpa@zytor.com>,
Dan Carpenter <dan.carpenter@oracle.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info
Date: Wed, 24 Feb 2016 11:13:09 +0800 [thread overview]
Message-ID: <20160224031309.GA17763@wfg-t540p.sh.intel.com> (raw)
In-Reply-To: <xmqq1t8319z0.fsf@gitster.mtv.corp.google.com>
On Tue, Feb 23, 2016 at 11:51:31AM -0800, Junio C Hamano wrote:
> Fengguang Wu <fengguang.wu@intel.com> writes:
>
> >> >> I have a mixed feeling about this one, primarily because this was
> >> >> already tried quite early in the life of "format-patch" command.
> >> >>
> >> >> http://thread.gmane.org/gmane.comp.version-control.git/9694/focus=9757
> >> >>
> >> >> Only the name is different (it was called "applies-to" and named a
> >> >> tree object).
> >> >
> >> > Either commit or tree object will work for us. We can use it in
> >> > v2 if you prefer tree object.
> >>
> >> Sorry, I think you misunderstood. By "only the name is different", I
> >> didn't mean to say that the tree object name should be shown as the
> >> old proposal did. What I meant but didn't explicitly say, as I
> >> thought it was sufficient to point at an old discussion thread, was
> >> that this was already tried and rejected. This round uses different
> >> name but does essentially the same thing as the old proposal, and I
> >> do not think I heard anything new that supports this patch against
> >> earlier rejection by Linus. That is what gave me a mixed feeling.
> >
> > I can understand the rejection by Linus in development process POV.
> >
> > However we are facing a new situation: in test robot POV, IMHO there
> > are values to test exactly the same tree as the patch submitter.
> > Otherwise the robot risks
> >
> > - false negative: failing to apply and test some patches
> > - false positive: sending wrong bug reports due to guessed wrong base tree
>
> I always get negatives and positives confused, so let me think aloud
> with an example. Let's say that somebody worked on adding a new
> feature based on v4.2 codebase and sent in a patch series. The
> series touched files in quiescent part of the system, these files
> are identical between v4.2 and the current codebase at v4.5-rc5, and
> the series applies cleanly to a "wrong" base tree at the tip of
> 'master'. But it turns out that the series uses an old API that was
> removed in the meantime. The test robot may say "the result of
> applying the series does not even build" and the developer would
> complain to you saying "You tested with a wrong version".
>
> I've already said that I can see the value this approach has for
> you. By having the developer state which commit the series was
> based on, it will shield you from such a complaint, because you
> would not use closer-to-tip 'master' as the base, but instead use
> v4.2 codebase for the test.
>
> As I said, what is unclear to me is what value this apporach gives
> to the project.
Problem arises when a developer based his work on a maintainer's topic
branch. The robot doesn't know that and tests the patch on v4.5-rc5,
which may trigger a false error because the patch depends on some
changes in that maintainer's topic branch. In that case, the error
report will be pure noise.
Thanks,
Fengguang
next prev parent reply other threads:[~2016-02-24 3:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1456109938-8568-1-git-send-email-xiaolong.ye@intel.com>
[not found] ` <1456109938-8568-2-git-send-email-xiaolong.ye@intel.com>
[not found] ` <xmqqmvqt8jgz.fsf@gitster.mtv.corp.google.com>
[not found] ` <20160223014741.GA21025@wfg-t540p.sh.intel.com>
[not found] ` <xmqqio1f3oi9.fsf@gitster.mtv.corp.google.com>
2016-02-23 9:17 ` Fengguang Wu
2016-02-23 9:23 ` H. Peter Anvin
2016-02-23 9:32 ` Fengguang Wu
2016-02-23 10:32 ` Dan Carpenter
2016-02-23 12:00 ` Fengguang Wu
2016-02-23 13:31 ` Dan Carpenter
2016-02-24 2:55 ` Fengguang Wu
2016-02-24 6:30 ` Junio C Hamano
2016-02-24 7:07 ` Fengguang Wu
2016-02-24 18:34 ` Junio C Hamano
2016-02-23 19:51 ` Junio C Hamano
2016-02-23 20:08 ` Eric W. Biederman
2016-02-23 20:35 ` Junio C Hamano
2016-02-23 20:46 ` H. Peter Anvin
2016-02-23 21:49 ` Eric W. Biederman
2016-02-24 1:40 ` H. Peter Anvin
2016-02-23 22:21 ` Stefan Beller
2016-02-24 10:31 ` Michael J Gruber
2016-02-24 6:19 ` Junio C Hamano
2016-02-24 3:36 ` Fengguang Wu
2016-02-24 3:13 ` Fengguang Wu [this message]
2016-02-23 19:56 ` Eric W. Biederman
2016-02-24 2:30 ` Fengguang Wu
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=20160224031309.GA17763@wfg-t540p.sh.intel.com \
--to=fengguang.wu@intel.com \
--cc=dan.carpenter@oracle.com \
--cc=ebiederm@xmission.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=julie.du@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=philip.li@intel.com \
--cc=torvalds@linux-foundation.org \
--cc=xiaolong.ye@intel.com \
--cc=ying.huang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®