Hello isar! Hello everyone! Questions: * When a v1 release to let the project show its maturity? * can we realistically use semantic versioning? Time-based releases instead? * A: Current state: Aiming for one release per year. * A: Proposals: more releases (quarterly), still following semantic versioning vs . * A: official decision on versioning would be very helpful * Would be nice to have an Isar porting guide. Do you plan to create one? * Meaning how to get a Debian image generated by isar in your custom hardware? * yes and no, there are no official Isar layers from SoC vendors. Using Isar would mean custom "BSP"... I assume in long run might require constant effort to keep it up to date. I mean kernel versions, packages etc. * A: Patches always welcome. improve getting started guide (explain basic concepts, links to working examples) * If I build a BSP based on Isar and provide to my customer, how my clients can get Isar support? * We should IMO refrain from using the term BSP. It has been over-used to the point where it no longer means anything. * Well, IMHO the term BSP is quite simple. In any case, if I provide my hardware customers an Isar layer to use where they can get support? for example if there is no Linux experts. * A: ilbers (or others) for payed support and trainings * Are there any plans to simplify running the testsuite / CI? * A: Planning to improve documentation. Test script patch from Cedric on the mailing list. * A: expect improvement patches in January * A: Execution of the testsuite should be much easier. A testing container / wrapper script is needed. * Should we use another test framework than avocado? * Pytest? Yes, for example,or unittest like in OpenEmbedded * A: avocado still not packaged by Debian. With avocado you can model dependencies between tests (with Pytest not). Avocado test results better readable (less output) than pytest? * A: full test suite takes 8h to run. With avocado, tests can be run in parallel on different machines, taking dependencies into account. * Would it be possible to make the test results visible publicly, e.g., by switching from Jenkins to GitHub? Voting for this! * A: Baurzhan: not ready for switching to GitHub. Ready to open jenkins to anonymous access. On GitLab the results are downloadable (zip) * A: Jenkins is legacy. * A: Wanted: production pipelines on GitLab with easily visible test results * A: todo: add link to GitLab CI in docs? * When sending a patch, it would be great to get a quick feedback whether basic pipeline tests passed and linting is correct * A: wish: when sending a patch, the user could specify which tests should be run? * A: OpenEmbedded is always running some (basic) tests on every received patch * What is the reason for applying patches via mailinglist instead of GitHub PRs? * A: same method as for Linux kernel. * A: barrier for newbies for using mailing list process for first time. PRs might be easier * A: we should improve docs regarding mailing list contributions. Simple setup guide * A: add automatic bot: if GitHub PRs are opened, a comment should be added with a link to mailing list procedure/Send initial message to mailing list including the patch from PR * A: in kas, both are accepted, if the user is not able to send a patch on the mailing list. * A: mailing list may give a better overview than PRs * It can take quite long till patches are applied... Have you considered improving this? * A: 5 working days for waiting for review. Now differentiating btw fixes and feats, to apply fixes faster * A: make this process transparent, nowhere the 5d are documented. * A: B: we can talk about adding a maintainer at Siemens * A: plan to move faster with the risk of breaking * Can we use conventional commits or decide on an official way how to structure them? * A: B: let's document this. * How will you get ready for the CRA? Are you aware of the large responsibility you face in the manufacturer role? * A: let's wait what the future brings * Cedric starting to see some downstream projects needing pre-installed container images and the not liking the idea of docker load on first boot. Anyone else seeing the same demands? docker uses a complex layout on disk making it impossible and not desirable to replicate. Pre-populating /var/lib/docker requires a running docker daemon... * A: send patches * Generall pain-points when switching or learning ISAR * A: understanding BitBake, Debian, kas... * Question to everyone: If there would be a public example layer for isar and cip-core features, what functionalities would you like to see there in practice? https://github.com/siemens/isar-demo/tree/main * A: todo: link the public layer in the isar repo * A: show read-only-rootfs in practice. mounting non-classical filesystems (/tmp tmpfs) * (Slightly off topic) paint points on CRA/Open source Contributions, technical based decisions,(CCTV example) etc: is there interest to bundle common pain points and try to address them more unified * A: * Why ISAR tool, and not the ELbe tool *