On Tue, Oct 28, 2008 at 8:02 PM, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote: > 2008/10/25 Daniel Berlin <[EMAIL PROTECTED]>: >> I have placed a continuous builder (IE it does one build per svn >> change) for GCC for x86_64 on an 8 core machine (nicely provided by >> Google), and it has results here: >> http://home.dberlin.org:8010/waterfall > > I think this is great and pretty! Would it be possible to keep a list > of the revisions that failed to build? That could be very useful for > reg-hunting. Could the system send an email to the author of the > revision that failed? > >> (I have not made it summarize the warnings yet, and these deliberately >> do not run the testsuite in order to keep up with the repository. I >> have more servers coming that will run builds that include running the >> testsuite). > > Well, it seems idle right now. And with the new parallel testsuite, it > shouldn't take so much time, so I think it could keep up with the > repository. It seems just a waste of resources to build once and then > build again somewhere else to run the testsuite. > >> In the next few days i will add a continuous builder for i686, as well >> as a server that accepts patches for testing on these platforms and >> spits back results in an hour or less, including the testsuite, so >> those who want to test things while continuing work can do so. > > Great. Although this does not seem such an important issue given the > existing Compile Farm.
The compile farm requires a lot of manual work for people (SSH keys, etc) who just want to submit a small patch, whereas upload through a browser or email does not. I will probably even make it provide a debuggable binary and core file for crashes. > > On the other hand, I seriously miss the patch tracker and I think I > was not the only one and we have probably lost a few patches along the > way. Any plans to bring it back? No The patch tracker was an experiment in trying to see if it would improve the rate of patches falling through the cracks. It had the secondary effect of getting some other patches reviewed quicker in some cases, because of those who paid attention to it. In reality, it didn't improve the rate of patch dropping in the areas that we were dropping patches. It guess it turns out those people specifically in charge of those areas didn't care if a long list of patches on a web page pointed to them :) It did improve the rate of patch dropping among those who have limited time to wade through email, I think, but there are better ways to present that info (IE "i am Diego Novilllo, give me the list of patches on the mailing list i could look at") Given that it's main goal was a failure, I don't see why i would bring it back, at least in that form. OTOH, If you want just something to tell you, as an individual reviewer, what patches sent to the mailing list are still waiting for your review, or we want to see about a general code review system that works with email as well as web, i may take a gander.
