lkml.org 
[lkml]   [2016]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH 1/1] format-patch: add an option to record base tree info
On Tue, Feb 23, 2016 at 12:35:12PM -0800, Junio C Hamano wrote:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> It is valuable for a testing organization to say "We tested this
> >> series on top of version X. We know it works, we have tested on a
> >> lot more hardware than the original developer had, we know this is
> >> good to go." It is a valuable service.
> >>
> >> But that is valuable only if version X is still relevant, isn't it?
> >>
> >> Is the relevance of a version something that is decided by a
> >> developer who submits a patch series, or is it more of an attribute
> >> of the project and where the current integration is happening?
> >> Judging from the responses from Dan to this thread, I think the
> >> answer is the latter, and for the purpose of identifying the
> >> relevant version(s), the project does not even care about the exact
> >> commit, but it wants to know more about which branch the series is
> >> targetted to.
> >>
> >> With that understanding, I find it hard to believe that it buys the
> >> project much for the "base" commit to be recorded in a patch series
> >> and automated testing is done by applying the patches to that exact
> >> commit, which possibly is no-longer-relevant, even though it may
> >> help shielding the testing machinery from "you tested with a wrong
> >> version" complaints.
> >>
> >> Isn't it more valuable for the test robot to say "this may or may
> >> not have worked well with whatever old version the patch series was
> >> based on, but it no longer is useful to the current tip of the
> >> 'master'"? If you consider what benefit the project would gain by
> >> having such a robot, that is the conclusion I have to draw.
> >>
> >> So I still am not convinced that this "record base commit" is a
> >> useful thing to do.
> >
> > So I don't know what value this has to the git project.
>
> Oh, don't worry, I wasn't talking about value this may have to the
> Git project at all. "The value to the project" I mentioned in my
> response was all about the value to the kernel project.
>
> > The value of Fengguag's automated testing to the kernel project is to
> > smoke out really stupid things.
>
> I'll snip your bullet points, but as I wrote, I do understand the
> value of prescreening test.
>
> What I was questioning was what value it gives to that testing to
> use "the developer based this patch on this exact commit" added to
> each incoming patch, and have Fengguag's testing machinery test a
> patch with a base version that may no longer be relevant in the
> context of the project. Compared to that, wouldn't "this no longer
> applies to the branch the series targets" or "this still applies
> cleanly, but no longer compiles because the surrounding API has
> changed" be much more valuable?
>
> In your other message, you mentioned the "index $old..$new" lines,
> and it is possible to use them to find a tree that the patch cleanly
> applies to, but it will not uniquely identify _the_ version the
> patch submitter used. IMHO, finding such _a_ tree from the recent
> history of the branch that the patch targets and testing the patch

Problem is, it's typically not clear what the patch "targets". Linux
is such a big project, there are dozens of maintainer trees and an
order more branches in their trees. The robot does a hard work trying
to guess what are the patches' targets, based on various hints like the
files being modified, the TO/CC list, the subject, etc. However it's
error prone -- even big maintainers cannot make a certain judgement
at times: "shall me or you take the patch?". Not to mention the
semi-private rules of co-maintainers, sub-maintainers and topic
branches. Sometimes people are backporting patches, hence "don't
test my patch on new RC kernels"; Or people may be working on cool
futurism patches that depend on more changes than the latest RC
kernel. To a robot, it's really hard to avoid stupid actions in such
a versatile bazaar. The "base commit/tree-id" under discussion would
be a perfect compass to guide the bot.

Thanks,
Fengguang

> on top of that tree (as opposed to testing the patch in the exact
> context the developer worked on) would give the project a better
> value.

\
 
 \ /
  Last update: 2016-02-24 05:01    [W:0.351 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site