As mentioned on the mailing-list, we would like to restructure the world repository. For the sake of convience I’ll paste the same text below:
We plan to convert world from a Genode repository into a repository housing goa projects and while doing so perform janitorial exercises. At the moment there is no ample schedule, so treat this announcement as a heads-up, but we would like to finish the restructuring process by the beginning of 2026. The following text briefly goes into the reasoning behind this decision and outlines the process.
The world repository was created as a gathering place for interesting components that enrich the Genode ecosystem but are not strictly placed under the same scrutiny as the ones in the base repositories. This lowers the bar for community contributions and makes it the perfect fit for ported applications and their dependencies.
By now the recommended way to bring existing applications over to Genode is by using goa instead of imposing Genode’s build-system on the contrib sources. We would like to reinforce that and anticipate that down the road goa will play a vital role also in creating new and non-ported Genode components.
The restructuring is thus intended to give goa projects that should be maintained by and large by the community a focal point and keeps the spirit of the world repository alive.
As a first step we are going to move the existing content of the world repository into the newly created ‘legacy’ sub-directory and will adapt the documentation, e.g.
REPOSITORIES += $(GENODE_DIR)/repos/world/legacy
retains the current state.
Next we would like to convert components into goa projects on a case by case basis choosing which we would like to keep maintaining, e.g. Java, and which are eventually destined for removal.
And this brings the community, i.e. you, into focus - please get in touch if there are components in world that you are currently use and plan on keep using, potentially becoming the custodian yourself.
And the build system itself lives in my Jamfiles, since I made significant changes to the Genode port of lib-ntfs3g/fuse and added a vfs plug-in (converted from the original fs_server).
So, as long as the prepare_port step still works in 2025/2026 and beyond, I guess I should still be able to build with only cosmetic changes, like appending the path with /legacy, even if the Genode-specific code (fuse.cc etc) disappears (I think).
If the prepare_port step disappeared and I had to take over the download/prep of libntfs then dunno, I’d have to look into it.
So overall – the genode-world migration will also give me more impetus to finally start exploring Goa for real too ^^ (currently down in the trenches but making progress with my Pi-based NFS and Samba setup, should be done soon-ish). And of course I’d love to see many more Genode-compatible packages published in genode-world (and why not, their binaries regularly built and uploaded to depot.genode.org), not necessarily 5000 but a few dozen more, for a start, would be nice to have.
Is there any intention to move away from GitHub? I know people in the Haiku community who are reticent to contribute there, knowing their work will be purloined to create so-called artificial intelligence. Still more are unenthusiastic about being hostage to a Microsoft (i.e. rival OS) managed platform.
Additionally I can see some advantages in restructuring the repository as proposed, by transferring the current code - on an “as needed” basis - to the “tabla-rasa” of a new hosting service.
If the prepare_port step disappeared and I had to take over the download/prep of libntfs then dunno, I’d have to look into it.
That would be the case as goa projects are prepared differently but legacy will be around for 2025 - you don’t have to jump ship immediately .
Is there any intention to move away from GitHub?
We monitor the situation but don’t actively pursue migrating to a different service at the moment. Some people already have their private repositories on codeberg (me included) and the way it is operated makes it an attractive option.
Additionally I can see some advantages in restructuring the repository as proposed, by transferring the current code - on an “as needed” basis - to the “tabla-rasa” of a new hosting service.
We haven’t considered switching the service for the time being. It is, however, something we could ponder.
Thanks for bringing this up. Admittedly, I haven’t seen the connection of the restructuring with the potential migration to another code forge. But if we contemplate a disruption anyway, the combination of both steps is an idea worth considering.
As hinted in a previous discussion I sympathize with the idea to move collaborative activities away from GitHub to Codeberg, which is a non-commercial foundation (Verein) operated in Berlin and wholly committed to Free and Open-Source software.
Taking the restructuring as opportunity to also move places would give us practical experience with moving away from GitHub while keeping the risk at a manageable level. (i.e., genode-world has an order of magnitude fewer issues than the genode main repository).
As tangential positive potential outcome, the move of our most community-focused repository to Codeberg as a non-corporate platform would strengthen the networking effect of Codeberg in the longer term while weakening the social lock-in of GitHub, at least for our community.
As a third plus, as Codeberg is based on the GPL Forgejo project, it would ultimately foster our autonomy. In the worst case - should Codeberg go belly-up - we could still move to self-hosting using Forgejo directly at any time with no migration risks.
This is the highlight of this discussion for me. I can think of many ways that one may end up “out of the frying pan, into the fire”. Nothing beats self-hosting! Back when TTS was a going concern, we were hosting our own fossil server (on a lowly haiku computer, no less), with full peace of mind. That kind of VCS is fully decentralized, meaning each clone is “equal” to other clones, including the ‘official’ server, so migrating from one to the other just involves changing the IP address of the server and that’s it. Good to see there exists a git-based system with similar level of decentralization.
At Gapfruit, we use the following ports currently hosted in genode-world:
googletest
jdk
jdk_generated
jsonc
libssh
libuuid
mbedtls
We extensively use the libssh-based ssh_server to instrument on-target tests on our CI infrastructure.
Therefore, we made a few additional patches for server/ssh_server to make the run scripts behave more robust on our pipeline.
Would you prefer that we provide them before you change the repository’s structure?
As we are using tool/autopilot to execute the test run scripts, it would be nice if there was an equivalent way to run Goa projects.