[Buildroot] More maintainers

Thomas Petazzoni thomas.petazzoni at bootlin.com
Sat Sep 5 20:38:35 UTC 2020


Hello Angelo,

On Sat, 5 Sep 2020 22:10:51 +0200
Angelo Compagnucci <angelo.compagnucci at gmail.com> wrote:

> Honestly, I can't see a CI here or we have a big misunderstanding: CI
> runs on review requests, not on the committed code.

As I've explained, we simply can't do that in Buildroot: running just
our current CI tests requires several hours of CPU time.

> Simple:
> 
> * A Developer opens a review request: the author only is notified, the
> CI starts running.
> * Commit has style problems, the author only is notified, red flag
> * Commit message has grammar/syntax errors, the author only is
> notified, red flag
> * Commit doesn't have a minimal defconfig to build on all
> architectures where it is supported: the author only is notified, red
> flag

I'm not sure what you mean here. You would require all commits to come
with a snippet of configuration that allows the commit to be build
tested ?

> * Commit compiles on some architectures and not on others: the author
> only is notified, red flag

There is no such thing as "Commit compiles" in the context of
Buildroot. Packages have optional dependencies, we have 3 C libraries,
we have 15 CPU architectures. How are you going to test all of those
combinations, for all patches that are submitted ?

If you have a magic solution for this, I'm interested!

> * Commit doesn't have a runtime test attached: the author only is
> notified, red flag

How would a runtime test be "attached" to a commit?

> * Commit has testing but testing fails, the author only is notified, red flag

What does "Commit has testing" means ?

> Imho, this is how a CI should work.

See above all questions that are raised.

In all what you have described, the difficult point is not e-mail vs.
Github/Gitlab, it is to define and implement the CI jobs/tests that you
are describing.

> That way, the autobuild could be even superfluous because each commit
> was already tested by CI. Yes, autobuild could catch some more
> intricate problems, but it can run less frequently.

See above: "commit compiles" is not something that can be answered
within a bounded time in the context of Buildroot.

I think you are confusing the type of CI that can be done on an
application or library, where indeed it is possible for every commit to
run the build on all supported platforms, run the unit tests, and have
good confidence that all combinations have been tested.

In the context of Buildroot, saying "a commit is good" requires
building thousands of different configurations: number of CPU
architectures * number of GCC versions * number of binutils versions *
number of C libraries * number of optional dependencies of the package
* number of optional dependencies of all dependencies of the package.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



More information about the buildroot mailing list