On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > On Mon, 2025-05-05 at 11:25 +0000, Richard Clark wrote: > > > > > But that brings me to a bigger question. > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > versions? Github is woefully lacking in proper version support. > > > I can't send random untested code to my customers. > > > > All code we push to Github went through our internal QA process, running > > compile checks for all our supported architectures as well as an extensive > > test suite on different platforms and configurations. So from that point of > > view I would say you can consider all code pushed to Github as > > “Fully-Tested-and-Blessed”. > > I don't have a strong opinion about quality assurance for people wanting to > provide solutions for paying customers, but I have personally wondered how I > might successfully and conveniently reproduce repository configurations when > creating new L4Re development environments. > > For example, if I decide to work on support for a new board, I might want to > replicate the L4Re configuration I have been using for another board. > Starting > from scratch, it was possible to use the ham tool, but despite it apparently > maintaining version details for the different repositories, it wasn't > particularly clear how one might preserve or export that metadata for further > use. > > I now see that there is another tool involved: > > https://l4re.org/getting_started/bob.html > > Although that doesn't seem to replace the ham tool: > > https://l4re.org/getting_started/make.html > > Naturally, one might say that this is the point at which anyone > serious-enough > about using L4Re would get in touch with Kernkonzept and start talking > business, but such a lack of clarity tends to suggest that either there > aren't > particularly adequate solutions for such fundamental needs or that any > adequate solutions that may exist aren't for people merely investigating or > evaluating the technology. > > Again, it isn't my concern if there's a business decision involved that > everybody feels comfortable with, and if there's a steady stream of > interested > customers that seems to justify such a decision, but I could easily see > potential users going elsewhere if the answer to simple questions is "talk to > us". Even in reasonably large organisations, hitting an approval barrier that > "talk to us" or "register your interest" represents can be a strong > disincentive, especially if other solutions exist. > > I accept that my opinion isn't important, however, since my own activities > are > confined to my own interests and driven by a general belief that L4Re > represents a reasonable foundation for certain kinds of systems. That there > isn't exactly much of a public community around L4Re could also be regarded > as > a disincentive for potential adopters, which is unfortunate. > > Paul
Hi Paul, thank you very much for your thoughtful message — it's really appreciated. First of all: your opinion absolutely matters. The input from users like you, who engage deeply and share candid feedback, helps us make L4Re better. While we are aware that L4Re is still quite niche and the community small, we want to support it as best we can and would love to see it grow. I think you're raising a different, but equally important, point compared to what Richard was asking. My original response focused on the idea of providing a fully tested release for a specific combination of software configuration and hardware, which is understandably difficult for us to maintain as part of the open-source offering given our limited resources. Your concern — about being able to reproduce a known working state of your development environment — is much more fundamental. You're right: this should be straightforward, and if it's not, then it's something we want to improve. Ease of use and accessibility are important to us, and sometimes we’re just too close to the system to see where friction arises — so thank you again for pointing this out. To clarify one key point: we don’t deliberately withhold features or usability improvements from the open-source version of L4Re to push people into commercial contact. That’s not our business philosophy. In fact, that would go directly against our goal of getting L4Re into more hands and making it easier to work with. Some of the convenience features — like release tagging — do exist in our customer repositories, but it’s more of a workflow habit than a conscious decision to exclude them from GitHub. No one had brought up the need for that kind of reproducibility in the open repo so far — and now that you have, let’s fix it. Would something like weekly tags on GitHub help you? For example, a tag like `l4re-2025-05-14` that you could use with `ham checkout` to reproduce that specific state? Also, ham already supports pinned revisions in the manifest (`revision` attribute in `project` tags), so you can share a complete and reproducible state that way as well. But I agree that this could be made more convenient. One possible improvement could be a `ham create-pinned-manifest` sub-command that generates such a manifest from your current state. That’s not trivial — it would require resolving different remotes and checking that all commits are actually reachable in one of the remotes — but it’s definitely doable. If you're interested, feel free to open a proposal or even an issue on the ham GitHub repository — we’d love to hear your thoughts or collaborate on a solution. Would any of these ideas help in your workflow? Do you have something else in mind? We're always happy to improve L4Re together with the people who use it. Best regards, - Marcus Hähnel Principal Engineering Lead -- +++ Register now for our workshop “Get to know L4Re in 3 days” on October 28–30. Learn to design and deploy secure system architectures for your product with L4Re: https://www.kernkonzept.com/workshop-getting-started-with-l4re/ +++ --- Kernkonzept GmbH Sitz: Dresden HRB 31129 Geschäftsführer: Dr.-Ing. Michael Hohmuth _______________________________________________ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
