Hello All, >> I appreciate your efforts. Actually this is something everybody is >> supposed to do before submitting a patch, and especially the >> custodians before submitting a pull request. >> Unfortually, that's theory only :-( > An unenforceable demand. :-( A build machine is the pragmatic solution, but > it puts the burden on the build machine maintainer. :-/ Thanks for > volunteering, Remy. :-)
As mentioned, I already needed a build machine for the u-boot-USB tree, so why not making it public while I have it anyway :-) And in my opinion, having a daily build does not mean anybody can skip the build testing part ;-) > Side note: I've been looking at BuildBot but haven't done anything useful. > I've looked at CruiseControl a few times and then I see how it does the > control logic in (haxtended) XML. Bleah! I currently do it by means of a plain and simple shell script and a crontab, and I (=crond) sent myself an email if the build fails, with the buildlog zipped attached. I can put the build results online as is (in plain text) and increasing the list of email-addresses is also very easy. I also started looking at CruiseControl.rb (some colleagues of me are using it) which seems to have git support on board, the web interface looks nice, but only reading the manuals, installing the stuff and so on, already took me more time than writing the shell script :-) And every tool that cost me more time to maintain than this shell script is a bad tool by design ;-)) I will investigate some more on tools to use (e.g. buildbot), and if I cannot find anything suitable, I will stick to the shell script for the time being :-) (being pragmatic) >>> Further, is there any interest to make the daily build results public? >>> * Is it appreciated if I post the build results in a daily post to the >>> mailinglist, _if_ there is a build failure? (No news is good news) >>> What format is preferred? >> Please do not post such results here. > Wolfgang: I would suggest another mailman list. Interested parties can > subscribe to it, disinterested parties can look in the list archives if they > need to. There probably isn't a need for long term archives, say 6 months > (~2-3 releases). >>> * Or is it preferred to post the results on a website? >> Yes, that would be beter, IMO. > Web sites are awfully easy to ignore/forget. :-/ That was my idea also, if I put it on a website, people need to poll for the status and will forget its existence if the build goes well for a while, and the benefits are gone. On the other hand, spamming the mailinglist with daily build failure messages is also not wanted, and I would not like that either! But (just thinking out loud), build failures are not allowed to happen, and when it happens at a certain time, is it so bad to sent it to the (or any) mailinglist? So, for example: 1. build broken -> sent mail (goto step 2, or 3) 2. build more broken-> sent another mail (goto step 2, or 3) 3. build repaired->sent mail... (goto step 4) 4. and then (forever) silence... until step 1 happens again. The advantage of using a mailinglist is that if a build gets broken, everybody gets informed immediately so actions can be taken fast, soon after the problem has been introduced, and the patches are still fresh in memory of the people who wrote them. Another advantage of the mailinglist is (let's be mean here) that it is public to see who breaks the build regularly, so we can bring that person to justice in public (gna gna) :-))))))) I also thought about sending only emails to people from whom patches are integrated since the last successful build. That would be a more ideal like situation, not bothering anyone who did not break anything... That kind of information could be extracted from the git log :-) Just TOL, keeping the discussion going ;-) Kind Regards, Remy _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
