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