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 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. > 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. Unfortunately, I never discovered this, but I assumed that you must have a way to capture the state of repositories in order to reproduce releases required by customers. > 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. > 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. I think they would be helpful. Previously, with Subversion, one could request a given release and get a versioned distribution of the software. The disadvantages were the poor performance of Subversion and the awkwardness of managing independent changes, as we all know. But that simplicity was also very useful. Thanks once again for following up and giving my concerns your consideration! Paul _______________________________________________ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
