On Tue, Feb 23, 2016 at 12:35:12PM -0800, Junio C Hamano wrote: > 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 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. -- 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