From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [autobuild.buildroot.net] Build results for 2013-01-28
Date: Tue, 29 Jan 2013 20:39:15 +0100 [thread overview]
Message-ID: <20130129203915.14e6a5fb@skate> (raw)
In-Reply-To: <CAKcgs2zUHb7CHnuBbPBeXNZ5jTiFJ7vZG0mu6TK50F57vSLw3Q@mail.gmail.com>
Dear Gilles Talis,
On Tue, 29 Jan 2013 11:30:45 -0800, Gilles Talis wrote:
> I could not find in buildroot documentation how these build failures
> were tracked and what the process was to triage and fix them.
> These issues do not appear in the bug tracking system.
> I assume this question has been asked many times, but I could not
> find the answer to it.
> Can you briefly describe how build failures are handled?
Sure.
We have autobuilders machines that are continuously building random
package configurations, from a set of predefined toolchain
configurations. Those run 24/7, and all the autobuilder machines report
the results of their build on http://autobuild.buildroot.org.
And then, once a day, an automatic e-mail is sent to the Buildroot
mailing list, with the list of build that failed.
There is for now no connection to the bug tracker. It is up to the
Buildroot community to have a look at the daily e-mail, pick some build
failure to work on, and submit patches to fix it. When a build failure
takes a long time to fix, we often send an e-mail to the list to say
we're working on it, or we discuss it on the Buildroot IRC channel.
There is no formal process for taking care of a build failure, except
by sending one or several patches to fix.
At the moment, we cannot easily integrate this with the bug tracker,
because a lot of build failures are duplicate. If we submitted one bug
for each build failure, we would have gazillions of duplicate bugs in
the bug tracker. It is not easy to automatically detect when two build
failures are the same, of when two build failures are different. So we
leave this analysis to Buildroot developers/contributors.
Do these explanations answer your questions? If you need more details,
do not hesitate to ask.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-01-29 19:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 7:34 [Buildroot] [autobuild.buildroot.net] Build results for 2013-01-28 Thomas Petazzoni
2013-01-29 19:30 ` Gilles Talis
2013-01-29 19:39 ` Thomas Petazzoni [this message]
2013-01-29 19:46 ` Gilles Talis
2013-01-29 19:59 ` Thomas Petazzoni
2013-01-29 20:16 ` Gilles Talis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130129203915.14e6a5fb@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.