Hi,

it was a pleasure for me to meet so many of you this Monday in Düsseldorf at the ELCE. As many as 17 current custodians and 2 prospective new custodians were present at the event:

Hans de Goede - Sunxi Alexey Brodkin - ARC Marek Vasut - USB Scott Wood - NAND Joe Hershberger - Networking Anatolij Gustschin - Video Heiko Schocher - I2C Stefano Babic - ARM i.MX Stefan Roese - PowerPC 4xx, CFI flash Wolfgang Denk - PowerPC 8xx, 82xx, 85xx, 5xxx, 7xx, 74xx Lukasz Majewski - DFU, OneNAND Tom Rini - Master of the git tree Pantelis Antoniou - MMC Daniel Schwierzek - MIPS Masahiro Yamada - Uniphier, Kconfig / Kbuild Simon Glass - x86, Driver model, patman, buildman Nobuhiro Iwamatsu - SH architecture Vince Bridgers - SoCFPGA (soon) Przemyslaw Marczak - PMIC (soon)

The six talks gave rise to a lot of good discussions and the presentation slides are now up on the wiki page[1].

The page is topped with a picture of the participants of the discussion round in the evening. I started adding the names of the people that gave me explicit approval to do so but I would like to extend this list somewhat further. Whenever there is an NA without a question mark, then I know the name and will fill it in when I get the approval. If there is a question mark behind it then I'm unsure and would be glad to get some help _in addition_ to the approval ;)

As promised, here are my notes that I took during the evening discussion - feel free to follow-up on individual items by cutting out the rest of the mail:

--------8<-----------------8<---------

* Open Discussion

** ARM core vs ARM SoC custodianship

Collection of patches should go to mainline in one bunch, rather than splitting them for every custodian repository. Individual custodians can ack parts of such a series. This should be the default - custodians should only pick up individual bits when those bits are pretty isolated.

** Getting new Custodians

Przemislav wants to apply as custodian for a PMIC tree. This should be handled by sending a patch to the ML in which he adds himself as a custodian. Once this is acked by Tom, the git repo can be set up.

** Testing

Problem is twofold:

- Hardware

Lots of hardware is available in a distributed fashion at individual places. A central lab will not happen, so one should maybe start collecting information on people volunteering to run testcases, say for every release candidate. (TESTERS?)

Boards should only be removed when they break during builds. There is no policy for automatic board removals. The idea of a "board watchdog" that times out after a certain amount of releases and has to be reset by a successful test was not greeted by enthusiasm. Most people believe this will not work.

Side-note: An interesting hardware project from the Novena guys can actually simulate an sd-card. With that setup one can feed test images easily to systems under test.

- Software provisioning

There are lots of test frameworks available but none of them seems to have no problem.

Tests in U-Boot can be successfully done in sandbox. Sandbox is a powerful test harness. Simon has a setup in which sandbox boots the U-Boot part of Chrome-OS including secure booting and a display.

Booting an U-Boot for tests from within U-Boot is still not supported and will not be.

** printf vs puts

Maybe the puts usages will be phased out when moving to debug macros of whatever kind. Such macros are wanted by everybody but a concensus on what they should look like was not reached.

No further feedback that "printf" without a format string needs to be converted into puts shall be given on the mailing list.

** switch malloc to malloc_or_die, as glib does

Motivation: The error paths of failing malloc calls are usually completely untested, full of bugs and they bloat the binary.

We have an "xmalloc" (sometimes known as malloc_dnf (do not fail)) in cli_hush that has the semantics of printing an error message and going into an infite loop on unsuccessful allocations.

The suggestion was to move all malloc calls to this semantics. It became pretty clear after a short discussion that there are situations in U-Boot where failing mallocs _need_ to be handled. So generally switching to this behaviour is not an option.

Adding an "opt-in" malloc outside of cli_hush with this behaviour was not greeted with much enthusiasm. A patch to the ML introducing such a malloc_dnf and switching users to it can then be discussed better.

** SoCFPGA patches

The fact that a large set of patches for the SoCFPGAs was merged after -rc1 was questioned as it does not 100% comply with the rules. The patches constrained to SoCFPGA were no (big) problem, but one of those patches broke mkimage and as such had an impact on the whole project.

The lesson should be - custodians should send out pull requests soon after the merge window opens up. Big chunks should not be pulled in after -rc1.

The -next branch should be declared rebaseable and be used more. Once -rc1 is released, things can then be pulled into the next branch. Only bug fixes should go into the later -rc's.

** Custodian expectations

It seems Albert doesn't like to pull from topic branches, so maybe simply do not offer topic branches for him to pull.

--------8<-----------------8<---------

PS: There were a few people taking pictures at the event and I'm certainly interested to see them. So if possible, send them over to me personally.

Thanks to everyone! Detlev

[1] http://www.denx.de/wiki/U-Boot/MiniSummitELCE2014