[U-Boot] [RFC] Build errors in u-boot mainline and daily builds

[Remy Bohmer]

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