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]
