The notes were taken by Florian Schmidt of NEC. Thank you
This has some actions on: Lars K, Xudong H, Doug G, Andrew C and Andrii A (who was not present)
We should certainly try and make progress on this as it has the potential to make life for code reviewers easier: it may be worth to organize a specific community
call to keep the momentum up
## Testing/building with Docker/Gitlab
Problem: different environments (especially distros), leading to
different gcc, binutil, qemu versions.
People report bugs that cannot be reproduced by the developers.
So maybe we should set up Docker containers for specific build environments.
There are also some Docker configs.
The containers themselves are on gitlab, not docker hub
### What OSs (architectures) should we support?
There is some discussion on whether we should support ARM (in addition
of x86) for this system, since ARM Xen is typically cross-compiled from
x86 anyway.
Stefano says that is true so far, but there is no need these days, and
points to his ViryaOS talk tomorrow.
Virya isn't ready yet, but this is what it's going to bring to the table
(late summer).
Many things in ViryaOS are not releveant here, but it has build
environments inside containers.
There's some kind of overlap, and this could also be used for testing.
Stefano and Doug want to discuss this a bit more between them to see how
their two systems compare.
Matt (ARM): we work on something very similar with a company called
infosifter
Infosifter hae experience with multi-architecture systems.
They build a multi-architecture build system, something like Travis.
Almost done (original plan: last week's dockercon)
The result would be a system that takes a dockerfile as input, and
produces several output i seeral architectures.
### Action points:
Matt: provide information about the tool (see above) that is released
soon, and heck how easily the current Dockerfile-based integration setup
(see xen.git:automation/build/)) would work with their
multi-architecture setup.
Doug: provide containerize script to the others to have a look how that
could help
## CI/CD
Doug has a prototype of the CI system running on gitlab.
He managed to get them to increase the free build minutes from 2000 per
month to 20000, which then is enough for the project so far. However,
the free-tier CI runners are slow because you get scheduled best-effort.
It would be helpful to have own gitlab CI runners on our own machines (VMs).
Lars tells Doug to write what is required and he'll talk to Ian to see
what can be done there. (Should be possible.)
Stefano: what would be *really* useful is a CI integrated with the
mailing list:
* take patch series from the mailing list
* apply to current HEAD
* do CI testing
* write report (with PASS/FAIL) as a mail reply to the 00 patch of the
series
Intel has something like that for QEMU (called patchbot?). Maybe they
can provide information about that to the xen mailing list, so we can
add something like that?
This would also be much better than maintainer having to manually pick
patches, push them to branches, and kick off CI runs.
One of the big advantages would be that it can save the reviewers a
*lot* of time, because they can immediately see whether they even should
review, or review other (working) patches.
### travis or not?
Travis is popular, well-known and stable, but it has some issues. Most
importantly to us, you either need to use the google cloud or specific
Dockerfiles (that you can extend with your own packages, but not do your
own clean-slate Dockerfiles).
Matt mentions shippable, but the consensus is that this is effectively
the same as the above gitlab integration.
### patchwork integration with patchbot?
If we have patchbot answering mails to the mailing list, it would be
nice if patchwork can use those replies to automatically tag the patch
series, for those who want to use patchwork.
Andrew points out that patchwork has ceaed functioning for the Xen
mailing lists since some mail headers were changed recently.
### checkpatch.pl
Status: still not quite done (same as last year)
###Action Points:
Lars K.: talk to Matt and Dough to see whether we can get dedicated
machines for the gitlab runners
Xudong H.: provide information about patchbot and how it could be used
for Xen patch management
Doug G.: document how the CI works, so that people can set up their own
gitlab-based CI, so that they can test their patches before they even
hit the mailing list.
Andrew C.: find out how to fix patchwork
Andrii A.: please update on the status of checkpatch.pl. Maybe we need
contributors to help out with getting this done
