Mini Summit 2014 Followup / Transcript of Open Discussion

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

Emacs seems a more likely candidate  to contain a mail system than the
mail system to contain an Emacs, so this is the way it was done.
                                            -- Bernard S. Greenberg
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [email protected]

Hi Detlev

Not for full day but
+ Michal Simek - Microblaze architecture, ARM Zynq

Feel free to identify me.

I don't think this was an agreement to be honest.
Merge early and merge often is golden rule for new SoCs. None is simply working on NAND when you don't have core SoC support or serial console.
It means preferred way is to merge sensible patch series from start and then extend it to the drivers exactly how you do your SoC bringup.

If you have bigger series touching some areas you need to get ack from custodian or you can be asked to split that series.

Thanks,
Michal

Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141020/96ebb0c9/attachment.pgp>

Hello Michal,

Thanks for adding yourself in - the names above were the custodians present during the introductory part so very likely you were not there from the beginning.

[...]

Thanks, done.

I tried to use the word "should" and not "must" to allow for case by case decisions, but I think there was an agreement on the direction of the proposal.

I believe we are in sync here.

Best wishes
Detlev

(7)  It is always something
(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three).
                                   -- The Twelve Networking Truths (RFC 1925)
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de