I’d like to suggest reorganizing our projects on GitHub, as some of them currently make little sense—I’ll elaborate on that further. We’ve discussed this before privately with @Joe and @Jamie, but it didn’t turn out to be very productive.
The key point—and a very simple change—is that webmin should be the single organization in GitHub hosting all our code and repositories, rather than splitting things across separate organizations like virtualmin.
That said, it makes far more sense to have repos like webmin/virtualmin-gpl or webmin/virtualmin-nginx rather than virtualmin/virtualmin-gpl or virtualmin/virtualmin-nginx.
As the current setup is a mess—especially with repos like virtualmin/cloudmin-installer—total chaos.
The good news is that moving a repo from virtualmin to webmin organization on GitHub is super easy. Old links will keep working forever, as long as Joe owns the virtualmin organization. Even better—API calls and scripts using old paths will continue to function without breaking anything!
For example, cloning the authentic-theme repo from an ancient location still works fine even seven years later.
And, to be clear, when we transfer a repository between organizations, GitHub preserves many settings—such as the repository’s history, issues, pull requests, and individual collaborator permissions, including access to the “Settings” tab and etc.
I realized this a long time ago and transferred all control of authentic-theme/authentic-theme to webmin/authentic-theme. That was the right move for the project.
With webmin as the only organization and the single source of truth for all of our code, it would make collaboration easier for users, bring more clarity to Cloudmin-related repos, and give webmin organization a much better granular control over all repositories, tokens, and permissions.
I can help and write a super simple Bash script to handle the migration, making it effortless and requiring no time from Joe to move everything.
So, let’s have an open discussion about the pros and cons of this.