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
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
