Consolidate all our GitHub repos under the `webmin` organization

Developers
1

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.

3 Likes
2

For me, moving all of the Virtualmin Repos to the Webmin organisation makes more sense that them being separate.

Your products need a more unified message and this will help convey that.

3

Completely agree—having everything under one clear org like webmin improves visibility and reduces confusion. Preserving links and settings during transfer is a huge plus—definitely worth doing.

1 Like
4

And since GitHub allows multiple organization owners with equal rights, there’s no “super-owner”—both owners can be on the same level. Sure, one owner can remove another, so mutual trust is key—but that’s not really a concern with @Jamie and @Joe as far as I can tell.

The nice part is that org members can have granular control—full access over repos they create, including deletion, while only having read access to others.

5

Other than visibility and consistency, what does this repo consolidation give us?

6

When I search for an issue, I can search the whole organisation (eg webmin, virtualmin, authentic theme) in one search instead of 3 to make sure it has not been reported already. There is a lot of crossover between these packages.

And let’s not forget that authentic theme has a lot of the base code for virtualmin in it which a lot of people don’t expect.

So searching before reporting would be better.

Issues can be moved from repo to repo as needed (not 100% if that can be done between organization)

7

The Authentic Theme org was merged with Webmin ages ago.

8

The fact that authentic theme has been moved to webmin, shows to me that virtualmin probably should be because more of Virtualmins code is actually in authentic theme that other places.

anyways, i have said my bit :smiley:

9

There are already plenty of reasons mentioned, I don’t think we really need more. But as I thought more of it, it’s just natural to think of GitHub like the server’s file tree—everything lives in /usr/libexec/webmin (or /usr/share/webmin or whatever), so it makes sense for everything to live under the webmin org in GitHub too.

Moreover, when all the stars, forks, and contributors sit in one place, the project shows up higher in search and on “Trending,” and new folks instantly see the whole Webmin ecosystem instead of scattered odds and ends.

10

I see your point, but I would still like to keep some separation between webmin (open source project) and virtualmin (commercial product).

1 Like
11

Then the action code needs to be moved from the themes into the virtualmin code base.

P.s. I know I have mentioned this before but this must be the logical outcome otherwise the virtualmin code is in authentic theme rather than just the virtualmin repo.

12

What is “the action code”?

13

The authentic theme has logic code in it for performing actions on the system, it is not just a theme. This is why sometimes the framed theme and authentic theme have issues the other does not.

I can dig out an example tommorow.

14

Oh, sure. We know about that. And it is a code smell I don’t like, but moving which org things are hosted in is not going to solve it (Authentic also has a bunch of code that affects Webmin and modules). There is no simple solution, someone needs to rewrite a bunch of code, and unless you’re volunteering, it’ll have to wait until someone has time to tackle it.

15

And, I would also like to point out that re-organizing orgs is also work that someone has to do, that takes time, and does nothing to move toward the goal you’re talking about. (And, I don’t want Virtualmin and Webmin orgs merged. They were created separately for reasons and I don’t see any good reason to change.)

16

I am not up to speed with programming yet (just finishing my dev environment and those pesky EOL needed to be sorted) but I was wondering if a script could split the 2 codebases, or even AI could do the job.

Maybe a HTML framework would be needed to make things a lot more programmatically rather than building raw HTML each time

e.g. form building on joomla