Github, Gitlab, or something else?

[Moonchild]

If paid options are on the table, then I guess we could look at RhodeCode as well...
https://code.rhodecode.com/
And the only other option I can think of beyond that is Redmine.
https://www.redmine.org/

I had a look at that and rhodecode doesn't have an issue tracker. It offers integration with a few issue trackers (including redmine which is just that, but not a code management solution...)
So the two can work together, but it seems about as disjointed as phabricator, with the problem additionally that they are tools maintained by different people/organisations.
Redmine as an issue tracker looks nice though.

GitHub itself has a self-hosted enterprise option as well, though it's not the cheapest and you probably considered that already.

GitHub as self-hosted has the same issue as GitHub-hosted: ultimately there's no option to have it under our control.
The only difference is that the deployment happens on an on-premises server, but the actual code deployed is still under full control of GitHub and if they decide to push Polymer and Chrome-Only support, then there's not a damned thing we can do about it.

[athenian200]

Redmine as an issue tracker looks nice though.

Redmine's issue tracker is nice, that was the main thing I noticed. Redmine has actually has been around since 2006 and has a TON of plugins. That was the main appeal of it to me, that it's old, established, looks like it can be scaled up or down depending on what we need. Redmine does have a repository feature, so you can import repositories into it and view recent changes, etc. The main thing it's missing apparently is pull requests. There was a plugin that could do PRs from within Redmine, but it looks like it's been abandoned. So it's not a complete solution for that reason... it was designed during the SVN days and was a complete solution back then, but isn't regarded as complete nowadays due to how Git works. So yeah, it looks like that won't work either, unless we're open to the idea of just moving issue tracking off GitHub and potentially accepting PRs from multiple sources in an issue tracker, whether it be via patches submitted on the tracker and committed directly, or using plugins to integrate GitHub/GitLab well enough to take in PRs to a self-hosted repo from there.

There is one big problem I just thought of with moving to anything other than GitHub or GitLab, though. The whole concept of a "Pull Request" seems dependent on the ability to compare publicly hosted repositories, correct? So if we switch to self-hosted architecture that only hosts our own repositories... doesn't that become basically impossible unless we allow other people to create entire forks of the repo on our own servers? I may be missing something, but it seems like without a community cloud hosted solution like GitHub or GitLab, we would be put in an awkward position where we have to either give developers the ability to push directly to branches within our repository (a huge security risk), clone the entire repository within Forge software hosted on our own servers (grossly inefficient and probably has its own security risks), or else require them to submit patches that would be committed by you (a lot more work for you). Regardless of what we choose, our workflow would change dramatically once we move to self-hosted infrastructure entirely, wouldn't it? Right now in my mind, it looks like we would have to do things more the way Mozilla did historically and the way other projects did them prior to GitHub.

I know that was probably something you thought of right away, and I'm just now catching up with... but what would we do about that? Does GitLab Enterprise have a solution that lets us get around that issue?

[Moonchild]

The concept of pull requests is usually based on comparing between branches on the same repo. It doesn't necessarily have to be across forks (that is actually a relatively new thing on GitHub). In fact, a pull request at its most basic is a request to merge a patch, to be "pulled from" someone else's working copy.
We'll have to see how the various options (Gitea, GitLab, Pagure, {???}) fit that in their individual workflow.
If need be I can use my in-house server if it turns out we need tons of disk space or cpu or ram (or a combination of them) but of course I'd prefer to have it in a DC - BUT that requires a good chunk of budget; co-lo isn't cheap either. I'm already paying close to a grand a year just for the VPSes I use for Pale Moon, and those are actually pretty economically provisioned.

[athenian200]

The concept of pull requests is usually based on comparing between branches on the same repo. It doesn't necessarily have to be across forks (that is actually a relatively new thing on GitHub). In fact, a pull request at its most basic is a request to merge a patch, to be "pulled from" someone else's working copy.
We'll have to see how the various options (Gitea, GitLab, Pagure, {???}) fit that in their individual workflow.
If need be I can use my in-house server if it turns out we need tons of disk space or cpu or ram (or a combination of them) but of course I'd prefer to have it in a DC - BUT that requires a good chunk of budget; co-lo isn't cheap either. I'm already paying close to a grand a year just for the VPSes I use for Pale Moon, and those are actually pretty economically provisioned.

Yeah, now that I think about it, that really isn't a big problem after all. Viewing a PR is basically the same thing as viewing a series of patches merged together into one big patch, and then being able to break it out and look at each individual patch separately as a potential commit. That's essentially what we do on GitHub when we look at a PR. The only difference I think is we'd have to ask people who we don't trust enough to give accounts on the self-hosted repo to generate a series of patches and submit them to our tracker. It seems like it's not totally foreign to how we've done things in the past. I think just having people work on their own repo locally, and then submit a patchset would both increase security and minimize the amount of server resources needed. The challenge is finding a web-based tool that handles the uploading and review of patchsets as elegantly as GitHub handles PRs, because there's really no reason why that couldn't be done. Having everyone create their own branch or fork on our server seems unnecessary. Seems more efficient to just have central repos that people clone locally, then submit their patchsets for review afterwards.

Anyway, I hope we can find something that minimizes the amount of server resources and money you have to spend, without significantly impeding the flow of development compared to what we have now. It's at least partially a resource optimization problem. That's becoming very clear to me as I think about this longer.

[New Tobin Paradigm]

Well I am still willing to do github or even bitbucket coordination (via Edge until we get WebComponents) and land pull requests manually to whatever systems we choose and keep em in sync for contributors as a transitional thing or whatever.

It could be an oppertunity to allow contributions from more sources than just whatever it is we use as our repo system.

[fatboy]

I am no developer, but what about this?

https://notabug.org/

[Moonchild]

I am no developer, but what about this?

https://notabug.org/

It's a good suggestion but similar to what's already being looked at.
If we're going for a gogs based solution then I'd rather go fo the most-developed and active one instead which would be Gitea.
It does seem like Gitea also has import capabilities from github using the API, which is a strong plus.

EDIT: Also seems like Gogs as-is is missing a bunch of functionality we might want, at least according to the comparison table Gitea has up.

[New Tobin Paradigm]

Here is a question. Why are we spending time looking for a code forge when we should be all working towards getting WebComponents working which would take the pressure off the need to deploy an infrastructure as soon as possible.

Yes, I agree having our own infrastructures even using them as primary resources is good but do you really expect everyone involved to instantly fracture their development flow? One that can be preserved temporarily by simply using something Chrome-based.

Will there be a plan to open it up to multiple avenues of contributing either via the primary forge or secondary services like github/bitbucket/gitlab with managed flow to the primary forge by mirroring and coordination?

I mean what is the plan here? Because it does seem like a huge amount of fracturing is gonna happen unless a management strategy is in place. Or is this just gonna be a unilateral decision and we must accept it or leave.

Cause I have no idea what is going on anymore because there has been a complete lack of cooperation and communication these past few months in general and specifically I feel quite shut out of the decision making that has been going on around here and it is only getting worse.

Why is this such a huge consern all of a sudden for you and why did I have to find out about it via this thread or find out about several things these past few months along with the rest of the forum? Also, why did this happen when it was known I was away from home and the full command of my resources?

What exactly is going on here?

[Moonchild]

I could ask you the same thing. Were you actually planning to inform me about Pagure without me bringing this up in this thread here? Or actually discussing the addons site before you unilaterally decided you were going to make a full rewrite again?

FTR i've been working full time on the next step needed for WebComponents which is getting ES modules completely up to spec. What time I've spent evaluating these solutions is a minimal chunk out of my time.
This thread is here because of the change in support I've noticed from GitHub's side (as in: no longer responding to my messages and no longer having a dialogue with me) and we need to look at this before things permanently break and then we need to have a rushed decision because there's no working alternative aside from using Chrome or Chredge. I'd rather be prepared and know what's available now, than being blindsided in a few months' time or however long it'll take them to Chromify things. And don't get me wrong, this is prepwork; I've no intention to rush getting a server and shoving everything across.

Will there be a plan to open it up to multiple avenues of contributing either via the primary forge or secondary services like github/bitbucket/gitlab with managed flow to the primary forge by mirroring and coordination?

I don't see myself having free time to arrange anything like that. Talk about fracturing things, that's the way to do it, no? I don't know what your plans are, but I don't particularly think syncing and mirroring every commit to multiple other software forges is a good use of time. What multiple avenues do you have in mind, anyway?

why did I have to find out about it via this thread or find out about several things these past few months along with the rest of the forum?

Because I don't feel like I need to check everything I think of or do with you before I make it known to the rest of the community. You're not shut out, but I'm also not giving you special treatment as if I have to get your permission -- do you think I need that kind of gatekeeping? And honestly all I've gotten from you lately has been resistance to everything I suggest or want to do, no matter which direction I want to go in, which doesn't particularly motivate me to discuss things with you -- since it's not really a discussion in that case.

Also, the timing of this thread is solely dependent on what happened in Github land and unrelated to your trip.

[New Tobin Paradigm]

Pagure flunked out for me. I wasn't properly informed of everything it required and I simply refuse to run it all. I had such high hopes it wasn't another Pythonic mess.. But it is.

I am out of ideas now. Guess I'll just go cgit and write my own issue tracker/ticket system/services software to go along with it. I hate everything.

[Tharthan]

Yes, I agree having our own infrastructures even using them as primary resources is good but do you really expect everyone involved to instantly fracture their development flow? One that can be preserved temporarily by simply using something Chrome-based.

Temporarily?

If the development team is not careful, this could lead to problems down the line, couldn't it? As Moonchild has noted multiple times, Firefox these days pretty much just makes weak imitations of Chrome code. What, aside from a fierce resolve and a striving for alternative methods, would stop for certain the same thing from happening here?

Can we get a sure declaration for you that striving for UXP will always be the goal here, and not to give up on that because it is more difficult than working off of Chrome-stuff?

Not trying to put you on the spot here, Tobin, but your post there makes you come off a bit too eager to look to Chrome-based stuff to deal with this issue. Please do correct me if I am misinterpreting you.

I just want to make sure that you have not lost heart on this, my good man.

This thread is here because of the change in support I've noticed from GitHub's side (as in: no longer responding to my messages and no longer having a dialogue with me)

I'm surprised that they outright would stop communicating with you in the way that they have, especially when they are making the site more Chrome-only. That almost seems like a definitive disapproval of Pale Moon's existence from them.

[athenian200]

The last piece of Forge software I can seem to find that wasn't mentioned is Tuleap:

https://www.tuleap.org/

Finally, I found this for source code management, but it has the problem of lacking a good built-in issue tracker. It's too bad, it looked like it supported a lot of plugins, too.

https://www.scm-manager.org

It's looking like we've got every viable forge software here already. It seems like if we want anything different than what's already been suggested, we'd have to pair an issue tracker with some kind of source code management tool.

Another thing I was thinking of is how we could use Git's inherently decentralized nature to avoid this becoming difficult for people to adjust to. Basically, Git was designed for distributed development. Each of us has our own local copy of the repo with a complete history. We also have the ability to add alternative remotes. Regardless of where our main repository is hosted, each individual contributor could simply go to a specific issue, give the URL of where their repo is hosted and the name of the branch they've been working on, and request that that branch be pulled into the main repo. So for instance, if my repo is hosted on GitHub, the maintainer could do... something along the lines of this to merge it into a non-GitHub repo (I didn't double check for accuracy, but it's a rough idea and I know it's possible for sure).

Code: Select all

git remote add athenian https://github.com/athenian200/UXP.git
git fetch athenian
git checkout athenian/solaris-fix
git merge master
git checkout master
git merge athenian/solaris-fix
git push origin

This kind of process could be done without using the browser at all. Not to say that I personally would want to stay on GitHub, just that if someone continued to have their repo there, there's a way to merge branches from it without using the browser. And since we already generally acknowledge that it's up to individual contributors to keep their branches and forks in sync to avoid merge conflicts, it seems like very little would actually have to change for the code to be moved to an on-premises repo. It seems like the more familiar you are with the command line interface of git, the less dramatically anything has to change as a result of the move.

[Moonchild]

The last piece of Forge software I can seem to find that wasn't mentioned is Tuleap:

I'm afraid that's not within our budget, also not under our control, software-wise (on-premises is the same idea as Github on-premises; meaning they control the forge), and is much too heavy because they focus on agile development which is at odds with our workflow (because that requires full-fledged devops and we can't even start on that because we don't do CI/CD). their presentations obviously aim at convincing management teams of larger organisations and not catering to developers' needs, so it'd be something for top-down heavy orgs, perhaps.

SCM Manager is... I don't know what it is, really. There are no demos, no examples, nothing but a description that is a little too concise.

Another thing I was thinking of is how we could use Git's inherently decentralized nature to avoid this becoming difficult for people to adjust to.

You can even do remote git repo addition and cross-fork merging in Sourcetree, not needing to touch the command-line. But that's a lot more additional work for whomever wants to review and merge the request. It'd be a number of steps backwards if we can use a forge that has this integrated.
Also your previous concern about storage of forks being inefficient; I'd think that any forge that does this kind of work will have efficient delta-only storage of repos and not create a full clone for everyone making a fork? I mean that would be rather silly because forks have common ancestry that would just be needlessly duplicated. It does mean however that it has to remain centralised.

---

So to recap: Pagure is the Pythonic mess I was thinking it was, and unmanageable. New options offered are a mismatch and/or out-of-budget. That leaves pretty much Gitea as our top contender now.

[Moonchild]

As Moonchild has noted multiple times, Firefox these days pretty much just makes weak imitations of Chrome code. What, aside from a fierce resolve and a striving for alternative methods, would stop for certain the same thing from happening here?

I think you misunderstood. "Using something Chrome-based" meant "using a Chrome-based browser to interact with GitHub" and not "using Blink in UXP"

I'm surprised that they outright would stop communicating with you in the way that they have, especially when they are making the site more Chrome-only. That almost seems like a definitive disapproval of Pale Moon's existence from them.

The GitHub team has always been responsive to web compatibility concerns raised with them re: the use of Pale Moon, and they have made adjustments for our use more than once when issues were raised with them. Even if they don't officially support us. The last two times I contacted their support, though, I haven't even received an acknowledgement or response. I don't know if they've even read it. I'm assuming they did because at least the "getRootNode" stuff seems to have been addressed after it was raised, but I'm left to just guess, here. I don't know what's going on with them.

[adesh]

It may probably be irrelevant but I like how gitea.io doesn't use Google for its mail, unlike everyone else.

[athenian200]

I'm afraid that's not within our budget, also not under our control, software-wise (on-premises is the same idea as Github on-premises; meaning they control the forge), and is much too heavy because they focus on agile development which is at odds with our workflow (because that requires full-fledged devops and we can't even start on that because we don't do CI/CD). their presentations obviously aim at convincing management teams of larger organisations and not catering to developers' needs, so it'd be something for top-down heavy orgs, perhaps.

I was actually looking at their Community Edition, which I don't think is under their control because you have to install and update it yourself. I probably should have clarified that, but the other points you bring up are valid.

SCM Manager is... I don't know what it is, really. There are no demos, no examples, nothing but a description that is a little too concise.

I believe it's along the same lines as RhodeCode, but more intended to be something you host yourself. It would only be worth a look if you wanted to pair it with an issue tracker. I believe that unless we are going with Gitea, the only other option is to pair Redmine (or some other issue tracker) with something that does code/repository management. And you seemed concerned that would be as much of a mess as Phabricator.

Also your previous concern about storage of forks being inefficient; I'd think that any forge that does this kind of work will have efficient delta-only storage of repos and not create a full clone for everyone making a fork? I mean that would be rather silly because forks have common ancestry that would just be needlessly duplicated. It does mean however that it has to remain centralised.

If it's a fully-featured GitHub clone, possibly, but I actually doubt most software does this out of the box. The whole concept of just clicking a button and making your own fork that's more like a branch was born on GitHub I believe. Hmm... so the intention is really that we remain centralized, everyone will have to move over to whatever is chosen? If having the ability of people to have and maintain their own forks on a server we're paying for is important, then it absolutely has to be the thing that's lightest on resources, have decent security, and most likely to be adopted without pushback. We could get away with a lot of solutions if we only have to host our own repository and an issue tracker, but needing this functionality means we only have so many good options.

So to recap: Pagure is the Pythonic mess I was thinking it was, and unmanageable. New options offered are a mismatch and/or out-of-budget. That leaves pretty much Gitea as our top contender now.

It's really looking that way to me as well.

https://hostedgitea.com/#pricing

There's an option out there that offers hosted Gitea for $37 a month. I don't know how that compares to the options you've been evaluating for hosting, but if it winds up being cheaper after you've figured out how much it costs to host Gitea, and we don't have to maintain it ourselves for the time being, it might be worth a look. Of course, using Gitea means we can migrate to a self-hosted solution at any time.

The more I consider this question, the more I feel the arguments in favor of Gitea are basically devastating. Here's why I'm reluctantly coming around to accepting that it's the only good option:

1. Most people on this thread have proposed something similar to GitHub or expressed a distaste for GitLab's interface, myself included. adesh proposed Gitea, Lootyhoof proposed Gitprep, Tobin proposed Pagure configured to look like GitHub. And I myself was looking at solutions that I thought would be configurable enough to be made to look more like GitHub, much like Tobin was (only difference is I wanted something that was configurable via server plugins rather than having to mess with code). That means if we can't get a solution that's similar enough to GitHub, it will be met with some resistance. Our best chance of keeping everyone together in a centralized environment is a near-perfect GitHub clone, in my estimation.

2. The fact that it's written in Go likely means it's light on resources. Regardless of how I feel about languages like Go and Rust, they've become the go-to languages for anyone who wants to make an application faster or less of a strain on system resources. Basically everything besides Phabricator or Tuleap Community Edition (which are in PHP) are written in "heavy" languages, like Python and Java. I have the luxury of using something heavier or older on my own system where the only one suffering is me, if I just don't like the best options for principled reasons. But on a server, there's no room for that. We absolutely have to use what will make the best use of system resources because every bit of resources we need costs more money, especially if we're running a multi-user system with actual source code moving back and forth. There's no room for bloat, and the only way to get more efficient than languages like Go or Rust is to use something written in C or Assembler (which as far as I can tell doesn't exist). That is why we see them on the server end increasingly whether we like them or not, and people who dislike them mostly favoring high-level languages like Python or Java. Google has much of the world's best engineering talent and runs a lot of servers with a lot of users, it only stands to reason they'd invent a programming language that's perfect for that use case. We would be using one Google technology mostly meant for their internal use, to avoid being consumed by the one they've dished out to consumers.

3. The popularity of Gitea likely means it's somewhat easy to deploy, relatively speaking. At the very least, there will be a lot of help with the deployment available in the community. Everything in the self-hosted Forge community right now that isn't corporate GitHub/GitLab seems really Gogs/Gitea-centered, with everything else having fallen by the wayside and mostly being used by people who chose something else years ago. That fact was incredibly frustrating to me as I was looking for alternatives. I found none that were viable, except maybe Redmine as an issue tracker, but that would still mean finding something it pairs nicely with.

4. Retraining time/costs. Let's face it, not all our developers are super familiar with Git on the command line, or good at learning something new. A lot of them are dependent on the way GitHub works to do their jobs, and have invested a lot of energy into learning it already. The less similar to GitHub our eventual final choice is, the more time we have to spend retraining those people, and the longer it will take to get development back to a pre-transition pace. Once again, Gitea solves that problem by being as similar to GitHub as possible.

In short... if we're really serious about having Forge software and a GitHub-like experience on our own server, then Gitea is basically our only option. Nothing else even comes close, in my opinion even GitLab (the other top contender) pales in comparison because it's simply too different from GitHub and there's no guarantee that they won't move to a fake on-premises option like GitHub did. If the providers of the software have a way to make you pay monthly for the on-premises option, they must have a way of disabling it if you don't pay one month, or their business model wouldn't work. And they can leverage that to control the product if they decide to implement undesirable changes, you can't just block it from phoning home and expect it to keep working. Which means they might let us defer updates for up to a year, but then a year later we might be right back here.

The only other possibility is to radically change the goal. We could also host a simple git server and an issue tracker, and let everyone work with the code using their own desktop git clients like Sourcetree or something. That would involve a severe learning curve, but also significantly lessen the resources required. There's also the option of trying something like Fossil or Mercurial that has a somewhat better web interface that can do more with repos out of the box, but I'm pretty sure we want to stick with git. If we are set on a GitHub-like experience on our own servers (I suspect we are), and we want it out of the box without having to develop anything ourselves, I genuinely see no other option than Gitea at this point. Everything else seems like a downgrade in a lot of ways.

To be honest, I pretty much knew that two pages ago even before you said it was feeling like Gitea and GitLab were the only real options. I knew that GitLab was the only other real corporate option, and Gitea was the only real open-source/free option. My gut was telling me that, and I was not happy about that fact. I didn't want to believe it, and I bet you didn't either, but there is literally nothing out there but decent paid options with a steep learning curve, disjointed garbage like Phabricator, a few complicated/messy Python options, and GitHub clones written in Go. That's what we have to choose from.

There is nothing out there that really appeals to my more idealistic side, but corporate/business me thinks Gitea could save us all a lot of time, money, and energy if we just compromise our principles just a little (GitHub is already a compromise in that department), bite the bullet, and use the ready-made package written in Go that practically everyone not on GitHub or GitLab is now using. We might regret it later on if we actually have to fork Gitea due to undesirable changes (I really hope we don't), but we can cross that bridge when we come to it. I do think someone from our team should start learning Go now just in case we have to patch it up ourselves, if we go this route.

[New Tobin Paradigm]

Gitea also uses node.js for the frontend.

I'm not happy with any of these so called solutions. No not happy at all.

For my self, I think I will install cgit and write my own issue tracker and hope eventually I can replace cgit with something of my own in time. Not like anyone ever helps me with my projects anyway so why do I personally need anything like a full on forge. I'll maintain my github org as a mirror for pull requests that almost certainly will never come.

Off-topic:

Or actually discussing the addons site before you unilaterally decided you were going to make a full rewrite again?

No no no, Moonchild. I told you what I was planning before I started my efforts on Phoebus Ascendent and solicited your opinion like always. I gave you my rational for it and the plan. You simply didn't accept why I wanted to do it that way.

For those who were not around at the time this is why I am doing a rewrite of Phoebus from scratch instead of modifying the existing codebase. It is plain and simple: the changes needed to take it to the next level are so numerous that to continue down the path I started would literally be more work and the bulk of it would be changed or scrapped anyway.

Phoebus 1.x was a non-sql creation to replace CMS Made Simple and the smattering of scripts and code fragments that was the original Pale Moon Add-ons Site. Phoebus 2.0 was orginally to be the sql and self-service panel version but because of Basilisk abd UXP it was almost totally rewritten to serve as a multi-application and thus multi-site configuration but even as such it was still based around the same basic concepts specifically the Add-on Metadata it was since was using albeit in sql not ini file. But the structure was pretty much the same thing and xpi files aside it is still largely using hardcoded arrays for junk like search plugins and the like.

What all this means is Phoebus as-is still suffers from a lot of limitations due to sticking to conceps and structures that should have long been abandoned like the manifest file in sql form which has a fatal flaw in it when it comes to previous versions being a single json encoded field that continues to grow and could start truncating leading to data loss and other parts that are still just hardcoded arrays.

It is a fact that Project Phoebus has been the single greatest creation I have ever accomplished and indeed has been the project that has grown and drove my continued development in.. well development. I think it deserves as all of you deserve for it and the service it provides to be the very best that I can single handedly offer. So I wanted to recreate it anew as if I was doing it today instead how I was doing things 4 years ago with a fresh perspective and not as a slue of adhoc features based on concepts and structures like ini files in another form.

To that end it is simply easier to start fresh and not waste time retooling the existing code where most of it would be thrown out anyway busting everything else around it requiring more time to fix that too.

All this I explained at the time and you were not only duely informed but properly consulted. Yes, I know you didn't like the idea but then again unlike me in relation to your project or UXP in general, how I approch Phoebus has very little to do with you personally because you nor anyone else actually contributes to it and I am soley on my own and if what it does or provides from an end user perspective or even an administration one is >= what it provided before then what difference does it make.

I am actually surprised you would even try to make a situational comparison here on this. Because it is not the same and you were included in the decision making process at the time. Also conserned because the last time someone questioned my intent, actions, capability, etc regarding Phoebus they were on a campaign to oust me.

Regardless, you were involved in it, you have always been included to the point of it annoying you. So do not pretend you weren't.

[Moonchild]

We have to approach this as a tool. A tool we can work with and a tool that is supported and we can reasonably maintain. Whether we're not happy about the use of a particular component or not doesn't matter if we don't have to touch that component ourselves.
So what if the front-end runs on node.js? It'll be the server spitting out the code; and honestly I think it's a lot better fleshed out and maintained than e.g. gunicorn or redis. if it's good enough for serving very high traffic websites, then it's good enough for our forge, I say.

And you can indeed use whatever you want for your projects, Tobin. Unfortunately, it'll likely reduce the chance of getting future help with them though, if only you have a good grasp of how it's being used, but that's your choice.

Off-topic:

No no no, Moonchild. I told you what I was planning before I started my efforts on Phoebus Ascendent and solicited your opinion like always. I gave you my rational for it and the plan. You simply didn't accept why I wanted to do it that way.

No, that's not how it went. You had already decided you were going to rewrite it and I merely questioned why, when phoebus 2.0 was working, questioning the invested time and effort in another rewrite. You brought up some decent points but that was just hashing out the details after already having stated you were making a rewrite, period. You didn't solicit my opinion beforehand, and didn't solicit my opinion for the implementation; I started that discussion by asking why, and we had a nice talk about it.
However, I wasn't going to otherwise interfere with your plans because you're ultimately the only one putting in the work for Phoebus and already had a hashed-out idea how to do it all, so who am I to resist that?

[Lunokhod]

Alibaba cloud code repository hasn't been mentioned although I couldn't find out much about it, I don't think many non-Chinese projects use it, searching didn't reveal any. It seems to offer either it's own interface or GitLab I think. Also Gitcafe although it's only in Chinese.
One thing about GitHub regardless of how well it works, is that it's still the most popular hosting service. So just being on GitHub gets extra visibility for a project. Try searching for Artix code repository, it's the old GitHub one that comes up, it was / possibly still is actually quite difficult to find the Gitea self hosted one if you didn't have the address, especially individual packages. Webcrawlers prefer hanging out on GitHub. Plus you can search on GitHub itself for projects.

[Isengrim]

One thing about GitHub regardless of how well it works, is that it's still the most popular hosting service. So just being on GitHub gets extra visibility for a project. Try searching for Artix code repository, it's the old GitHub one that comes up, it was / possibly still is actually quite difficult to find the Gitea self hosted one if you didn't have the address, especially individual packages. Webcrawlers prefer hanging out on GitHub. Plus you can search on GitHub itself for projects.

A lot of projects that host mirrors on GitHub often include links in their Readme files to point to their non-GitHub main repos. Even if you choose to abandon GitHub, leaving a link to your new repo is still good practice. I assume the PM team would follow suit.