Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
Dear Hackers, On Mon, 2025-05-19 at 17:01 +0200, Marcus Hähnel wrote: > On Wed, 2025-05-14 at 22:01 +0200, Paul Boddie wrote: > > On Wednesday, 14 May 2025 16:52:48 CEST Marcus Hähnel wrote: > > > > > 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. > > > > I can understand that it can be easy to overlook. How many times has one > > seen > > missing tags in public repositories because Git makes it easy to forget to > > push them? I also understand that publicly tagging releases can make > > mistakes > > difficult to rectify, but I suppose this is just another hazard of release > > management, and eventually we all get used to making "patch" releases. > > I talked to our release engineers and we'll try to integrate this into our > release process in the future, such that > specific source states that ran through our QA will be tagged accordingly, > also on GitHub. Indeed internally we already > have them tagged, but these tags aren't transferred over to GitHub. We have started to integrate a process into our release pipeline to tag the releases. This hopefully helps your use-cases to better get back to a known-good state for the specific setups you have. See an example here: https://github.com/kernkonzept/mk/tree/r-2025-W24 The release tag schema for now is r--Www (with y = Year, w = week, W/r = literal W/r). We might re-evaluate that schema if we see that it is not perfect, but for now it should be OK. Right now the latest release has been tagged as r-2025-W24 (see above) and we will make sure future releases will be tagged as well. You can check out this state, for example when using ham, through: `ham checkout r-2025-W24` (and to optionally create a local branch named my-project as well and avoid the detached head messages) `ham checkout -b my-project r-2025-W24` Thanks a lot to Matthias Lange who implements this into our release pipeline. Best regards, - Marcus -- +++ 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]
Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
Hi Paul, thanks also to you for the valuable feedback, also with regards to ham in the other part of the thread. We're sure to take all of it into consideration! Regarding some other points: On Wed, 2025-05-14 at 22:01 +0200, Paul Boddie wrote: > On Wednesday, 14 May 2025 16:52:48 CEST Marcus Hähnel wrote: > > > 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. > > I can understand that it can be easy to overlook. How many times has one seen > missing tags in public repositories because Git makes it easy to forget to > push them? I also understand that publicly tagging releases can make mistakes > difficult to rectify, but I suppose this is just another hazard of release > management, and eventually we all get used to making "patch" releases. I talked to our release engineers and we'll try to integrate this into our release process in the future, such that specific source states that ran through our QA will be tagged accordingly, also on GitHub. Indeed internally we already have them tagged, but these tags aren't transferred over to GitHub. > > 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? > > It might, but I think the challenge is then applying such tags to a large > number of repositories. Naturally, one can write scripts to synchronise all > those repositories, but isn't that what ham is supposed to achieve? As mentioned above we already do this :) We need to test a consistent state anyways, so it is easy to tag the tested state. And checking them out is indeed as easy as calling `ham checkout name-of-the-tag`. > Richard also mentioned various other packages that ham doesn't cover, and > having been working with the software for a long time now, there are still > various packages that I have needed to retrieve from the Subversion > repository > for L4Re because they were never migrated to GitHub. I can understand that > those packages are no longer a focus, and I have even eliminated some of them > from my own environment, but they might still be used by the L4Re > demonstrations. We'll try to migrate as much of this over to GitHub in the future as we reasonably can support. If you want to have your own repositories you can also have multiple remotes that you can then use in the project tags using the remote attribute of the project tag. Again, this is similar to how repo does it. > > 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. > > It is something I could consider working on, but it would be joining a long > list of other tasks. Sure :) That's always the problem, there's just too little time. But at least now the idea is out there and either someone from us will find the time to do it or hopefully someone from the community will step up. So thanks for bringing it up! Again, thanks a lot for the input and for all your valuable contributions that you already brought to the list! Best regards, - Marcus -- +++ 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]
Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
Hi, > 1) using a project manifest format (github.com/kernkonzept/manifest) aligns > well with the repo tool (gerrit.googlesource.com/git-repo), which is used > by AOSP and several other large projects consisting of 100+ sub-projects, > each with its own commit history, etc. In practice, we could explore > applying this tool for version management in our current project as well. > repo also has broader documentation and more usage examples available > online, which could be beneficial. > > 2) with minimal changes, the manifest could also be used to create local > versions of repositories. For example, the following command can be used to > initialize a local mirror based on a manifest (my rpersonal example): > repo init --mirror -b repotool_support -u > https://github.com/EugeniyKozhanov/l4re_manifest.git > repo sync -j9 > Indeed ham is modeled after repo and we try to keep the format that ham accepts somewhat compatible with repo where that's feasible. So one should be able to use our manifests with repo, though we don't test it ourselves right now as far as I am aware. Ham has some additional features which are primarily valuable for our internal use and dealing with specific QA / CI use- cases and customer specific requirements. > […] > *P.S.* It's possible that *Hammer* is also capable of doing all of this. > But I must admit — even after trying to understand its philosophy, I found > it very difficult to use without extensive documentation, examples, or > community support. I even had to recall some long-forgotten Perl skills, > which I was really hoping to avoid. I worry that many newcomers might be > discouraged from even starting with it if they can’t easily understand how > it works or install the missing dependencies on their systems ( > https://github.com/EugeniyKozhanov/ham/pull/1/files). Thanks for that valuable input! We might consider switching the explanations to `repo` in the tutorials, if people find it easier to use and are more comfortable with that tool. I'll bring it up with our release engineers. Best regards, - Marcus > > Thanks! > > Best regards, > > Am Do., 15. Mai 2025 um 00:34 Uhr schrieb Richard Clark < > [email protected]>: > > > Marcus, > > > > I, for one, rather than having to learn yet-another-tool that doesn't > > quite do what I want, would rather that > > you have a fully-blessed-and-tested release all rolled up in a tar (or > > zip) file for download. You could even have > > a git repo just for the tar files. One caveat, being that it must contain > > ALL the repos and possible little pieces > > that could possibly go with it. One thing I hate about git is sub-repos > > that get lost or are not pulled down and > > cause severe headaches trying to match versions. Like lwip, or > > virtio_switch, or any of the other couple dozen > > packages that don't get pulled down with the new ham build process. I'd > > like to be able to go to one place, > > use a command I already know, and get a fully functional, fully populated, > > "blessed" version. You do have your > > old downloads site with a tgz file, but even that doesn't contain all the > > packages any more. This is the frustrating part. > > I need a way to get a snapshot of everything that could possibly go > > together in a release whether I need it or not, because > > some day I will need it and then the version I need will no longer be > > available. So, not a "demo" or "example" > > version, but a full-source-everything-including-the-kitchen-sink version. > > > > > > Thank you for considering our opinions! > > > > > > Richard > > > > > > -Original Message- > > From: Marcus Hähnel > > Sent: Wednesday, May 14, 2025 10:53 AM > > To: Paul Boddie ; [email protected] > > Subject: Re: Configuration, component and repository versioning (was Re: > > Upgrade issues. VM won't start.) > > > > 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 +, 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 proces
Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
On Thursday, 15 May 2025 12:57:53 CEST Eugeniy Kozhanov wrote: > > I’m just an outside observer, but I’d like to share my proposed solution in > the hope that it might help address some of the challenges you're facing. > > 1) using a project manifest format (github.com/kernkonzept/manifest) aligns > well with the repo tool (gerrit.googlesource.com/git-repo), which is used > by AOSP and several other large projects consisting of 100+ sub-projects, > each with its own commit history, etc. In practice, we could explore > applying this tool for version management in our current project as well. > repo also has broader documentation and more usage examples available > online, which could be beneficial. I seem to remember L4Re using a different tool that I thought was repo, but just checking in some old source distributions, I see that it was a tool called repomgr, written in Perl, that wrapped Subversion in a way that might be comparable to what repo does for Git. Another benefit of repo appears to be its availability in distributions like Debian, so that there is no need to download another tool. Unless I am getting confused with repomgr again, I seem to remember encountering some projects where users were encouraged to wget/curl the repo tool from some URL, which then requires the user to inspect the source code for potentially undesirable behaviour. (There can sometimes be hostility from developers when one questions whether a tool can be trusted, particularly if those developers do not perceive value in software distributions, but even if the intentions of the developers are pure, it doesn't always prevent them from having some very strange ideas about what a program should be doing. In some cases, such ideas may not entirely align with responsible practice.) [Overview of repo capabilities] Thanks for this brief overview! > *P.S.* It's possible that *Hammer* is also capable of doing all of this. > But I must admit — even after trying to understand its philosophy, I found > it very difficult to use without extensive documentation, examples, or > community support. I even had to recall some long-forgotten Perl skills, > which I was really hoping to avoid. I worry that many newcomers might be > discouraged from even starting with it if they can’t easily understand how > it works or install the missing dependencies on their systems ( > https://github.com/EugeniyKozhanov/ham/pull/1/files). I am someone who likes to develop my own tools when I perceive that the existing ones do not perform in the way I would like. However, beyond ergonomic considerations of a tool itself, I think it also helps to use technologies that many people understand or are able to learn and use effectively. In this case, there is a trade-off between what the original developers are comfortable with and what potential contributors are able to use, which one also sees in projects like Debian where a lot of the tools happen to be written in Perl. I also used Perl in a professional environment about thirty years ago, revisiting it on brief occasions to maintain legacy systems, but I would hesitate to interact with a Perl code base now. Thank you for your perspectives on these issues! Don't worry about being an outside observer: that is also my position. Hopefully, you might become familiar with the technology and a contributor to the broader community. Paul ___ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
Hi everyone, > I want, would rather that you have a fully-blessed-and-tested release all rolled up in a tar (or zip) file for download it seems like a suitable solution for one-off cases. However, I believe it may lead to significant overhead when maintaining the final product, as it would require manually tracking the history of each package and compiling change logs. In my opinion, it's sometimes worth putting in a bit more effort at the beginning to ensure a smoother path forward later on. :) I’m just an outside observer, but I’d like to share my proposed solution in the hope that it might help address some of the challenges you're facing. 1) using a project manifest format (github.com/kernkonzept/manifest) aligns well with the repo tool (gerrit.googlesource.com/git-repo), which is used by AOSP and several other large projects consisting of 100+ sub-projects, each with its own commit history, etc. In practice, we could explore applying this tool for version management in our current project as well. repo also has broader documentation and more usage examples available online, which could be beneficial. 2) with minimal changes, the manifest could also be used to create local versions of repositories. For example, the following command can be used to initialize a local mirror based on a manifest (my rpersonal example): repo init --mirror -b repotool_support -u https://github.com/EugeniyKozhanov/l4re_manifest.git repo sync -j9 3) additionally, you can create mirrors for each release and use them to clone and rebuild the entire project tree with a single command. This approach is almost like using .tar archives, but with the advantage of preserving full commit histories and enabling centralized synchronization across all projects. 4) you can also centrally tag your set of subprojects in your local mirror. This makes it easy to mark consistent states across all components of your system and later reference or rebuild them as needed, with full traceability: repo forall -c 'git tag -a v2025.05 -m "Release tag for May 2025"' repo forall -c 'git push origin v2025.05' *P.S.* It's possible that *Hammer* is also capable of doing all of this. But I must admit — even after trying to understand its philosophy, I found it very difficult to use without extensive documentation, examples, or community support. I even had to recall some long-forgotten Perl skills, which I was really hoping to avoid. I worry that many newcomers might be discouraged from even starting with it if they can’t easily understand how it works or install the missing dependencies on their systems ( https://github.com/EugeniyKozhanov/ham/pull/1/files). Thanks! Best regards, Am Do., 15. Mai 2025 um 00:34 Uhr schrieb Richard Clark < [email protected]>: > Marcus, > > I, for one, rather than having to learn yet-another-tool that doesn't > quite do what I want, would rather that > you have a fully-blessed-and-tested release all rolled up in a tar (or > zip) file for download. You could even have > a git repo just for the tar files. One caveat, being that it must contain > ALL the repos and possible little pieces > that could possibly go with it. One thing I hate about git is sub-repos > that get lost or are not pulled down and > cause severe headaches trying to match versions. Like lwip, or > virtio_switch, or any of the other couple dozen > packages that don't get pulled down with the new ham build process. I'd > like to be able to go to one place, > use a command I already know, and get a fully functional, fully populated, > "blessed" version. You do have your > old downloads site with a tgz file, but even that doesn't contain all the > packages any more. This is the frustrating part. > I need a way to get a snapshot of everything that could possibly go > together in a release whether I need it or not, because > some day I will need it and then the version I need will no longer be > available. So, not a "demo" or "example" > version, but a full-source-everything-including-the-kitchen-sink version. > > > Thank you for considering our opinions! > > > Richard > > > -Original Message- > From: Marcus Hähnel > Sent: Wednesday, May 14, 2025 10:53 AM > To: Paul Boddie ; [email protected] > Subject: Re: Configuration, component and repository versioning (was Re: > Upgrade issues. VM won't start.) > > 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 +, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > vers
RE: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
Marcus, I, for one, rather than having to learn yet-another-tool that doesn't quite do what I want, would rather that you have a fully-blessed-and-tested release all rolled up in a tar (or zip) file for download. You could even have a git repo just for the tar files. One caveat, being that it must contain ALL the repos and possible little pieces that could possibly go with it. One thing I hate about git is sub-repos that get lost or are not pulled down and cause severe headaches trying to match versions. Like lwip, or virtio_switch, or any of the other couple dozen packages that don't get pulled down with the new ham build process. I'd like to be able to go to one place, use a command I already know, and get a fully functional, fully populated, "blessed" version. You do have your old downloads site with a tgz file, but even that doesn't contain all the packages any more. This is the frustrating part. I need a way to get a snapshot of everything that could possibly go together in a release whether I need it or not, because some day I will need it and then the version I need will no longer be available. So, not a "demo" or "example" version, but a full-source-everything-including-the-kitchen-sink version. Thank you for considering our opinions! Richard -Original Message- From: Marcus Hähnel Sent: Wednesday, May 14, 2025 10:53 AM To: Paul Boddie ; [email protected] Subject: Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.) 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 +, 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
Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
On Wednesday, 14 May 2025 16:52:48 CEST Marcus Hähnel wrote: > > thank you very much for your thoughtful message — it's really appreciated. Thank you for taking the time to respond! I didn't really expect such a comprehensive reply, so it is much 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. It is reassuring to hear that you take feedback into consideration, even from those of us who are not directly contributing to your work or, indeed, your business. > 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. I completely agree that if someone is in need of something that requires an investment of time and resources, then they should either invest their own time and resources, which is effectively what I have done over the last few years, or they should be prepared to compensate others for that work. Nobody should be required to do something for someone else for nothing - there is already too much of that happening in the open source world - not that any such request was made, I should add. Productive access to specific hardware configurations has always been a challenge for software environment developers, and the collaboration required to deliver robust support for a given hardware platform can be difficult to coordinate. Even with today's hardware, mostly inexpensive from a historical perspective, there is still a substantial cost in developing the corresponding software support. > 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. I think it is fine to encourage people to make contact and to discuss opportunities, and I don't seriously believe that people are being herded in the direction of commercial support, but any kind of obstacle or hurdle in the independent evaluation of a technology can be dissuasive. Some evaluators are more likely to move on and look at other things than to cultivate some kind of dialogue. This doesn't only happen in a commercial context. On plenty of occasions in academia, I saw researchers encouraging others to get in touch, in order to work around deficiencies in the way they had communicated or published their work. I also saw the long-term effects of this, where people could not account for what they had published after only a few years, with this emerging when I was actually making contact with them to try and distribute their originally published data. Empowering other people as much as possible or practicable may eventually return such favours. When I return to my own work after a substantial period of time, it is almost as if I am just another person taking a look at it, too. > 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. I can understand that it can be easy to overlook. How many times has one seen missing tags in public repositories because Git makes it easy to forget to push them? I also understand that publicly tagging releases can make mistakes difficult to rectify, but I suppose this is just another hazard of release management, and eventually we all get used to making "patch" releases. > 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? It might, but I think the challenge is then applying such tags to a large number of repositories. Naturally, one can write scripts to synchronise all those repositories, but isn't that what ham is supposed to achieve? Richard also ment
Re: Configuration, component and repository versioning (was Re: Upgrade issues. VM won't start.)
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 +, 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
