ebiederm@xxxxxxxxxxxx (Eric W. Biederman) writes: > Junio C Hamano <gitster@xxxxxxxxx> 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 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html