From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] Suggestion for building all boards
Date: Mon, 14 Oct 2013 11:45:37 +0200 [thread overview]
Message-ID: <20131014114537.17e49e50@lilith> (raw)
In-Reply-To: <CAPnjgZ1kCmqf00BmMc3XMUKnQC+ZEFarmY+wqJsKpvWotDgg4w@mail.gmail.com>
Hi Simon,
On Fri, 11 Oct 2013 16:00:37 -0600, Simon Glass <sjg@chromium.org>
wrote:
> Hi Masahiro,
>
> On Fri, Oct 11, 2013 at 5:29 AM, Masahiro Yamada
> <yamada.m@jp.panasonic.com> wrote:
> > Hello experts, custodians.
> >
>
> > To sum up my suggestion,
> >
> > - Collect pre-built suitable crosstools for all architectures
> > on U-boot ftp site.
>
> Great idea. If you can organize a tarball (or more than one) and a
> place to put it then we could make buildman fetch and setup
> automatically.
>
> >
> > - Check all boards automatically using those recommended
> > crosstools and post the result to the mailing list.
>
> Would be very helpful.
>
> >
> > - Add new status to boards.cfg to mark boards with a problem.
>
> This is for boards that are already broken I think.
There is some discussion about the Status field in boards.cfg, which
might result in moving it from its current "build/don't build" semantics
into something more like "maintainers mentioned at the end are active /
inactive, but the board still builds anyway".
Still, boards.Cfg is for long-term board info, whereas the build
breaks discussed here are short-term: if someone submits a patch which
breaks some board, we don't apply it until there is a new version that
fixes the break. Granted, we may detect board breaks after a patch is
applied, but then we as the submitter to provide a separate fix patch
within the same release cycle.
Also, adding some "builds / doesn't build right now" info in boards.cfg
will IMO cause either one of two bad side effects: an observable volume
of patches submitted just to keep boards.cfg up to date wrt which board
builds or not; or a burden to submitters whose patch (series) break or
fix some board(s) and who would then have to also update boards.cfg
with this.
I don't think we want to ask any submitter to add this to their work,
or even to build-test across all of U-Boot's boards to see if they're
breaking some board they don't know in an architecture they know nothing
about. That's for custodians to do, not for submitters.
Amicalement,
--
Albert.
prev parent reply other threads:[~2013-10-14 9:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 11:29 [U-Boot] Suggestion for building all boards Masahiro Yamada
2013-10-11 12:09 ` Stefan Roese
2013-10-11 22:00 ` Simon Glass
2013-10-14 9:45 ` Albert ARIBAUD [this message]
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=20131014114537.17e49e50@lilith \
--to=albert.u.boot@aribaud.net \
--cc=u-boot@lists.denx.de \
/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.