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,