@Patrick , you mentioned that Phabricator still exists correct? I was thinking we should discuss how we can get rid of this tool, and the overhead of running it.
I think an issue tracker would be a good thing, although I understand handling it through discourse. This is something I would happily take on and manage.
Github has a good issue system, but I think we could consider other tools. plane.so comes to mind
The usefulness of phabricator was limited. If I catch a but before a user reports it, I could be pretty much assured that it will be duplicated in the forums. Or once a bug was reported in the forums, I’d have to open a ticket on phabricator. If a bug is fixed, I’d have to post in two places. That overhead isn’t great.
Some people presumably prefer opening tickets on github due to the network effect so they don’t have to create a ticket here.
github is non-ideal in case it decides to become hostile to Whonix or dong other (non-targeted) weird things.
Specifically now that phabricator randomly starts breaking. There’s a phabricator fork that might be fixed but deprecating phabricator would be better nonetheless.
Somehow its contents should be migrated somewhere.
It needs to be done at some point before loosing its contents (except from web archive).
It has an API i believe, so we can pull the data out programmatically
I am not an expert on his matter, however I don’t see a reason why would you be using phabricator in first place? I never saw a FOSS project use it before. Why not a Gitea instance? or Codeberg? They’re both FOSS, keep it simple and work well with Tor
Phabricator is an open source project. It was integrated years ago. It did not succeed as a project and we suffered the consequences. Tons of issues live on https://phabricator.whonix.org/, and we want to get rid of it.
As a whole, hosting applications is not what we want to spend our time doing when we can avoid it. We have discussed gitea/codeberg before, but this sort of thing takes time away from meaningful development tasks. Github is fine for us for now. Gitlab was good but we ran in to storage limit issues.
I would like to use a more modern FLOSS Jira alternative for ticket tracking, but we get by with discourse for now.
self hosting is simple until it isnt. It takes time and resources. It costs money. There is DNS, TLS, server configuration, software dependencies, updates, and other things to maintain. On top of that, you have the issue of maintainers disappearing…when we go away, all it does is leave patrick with a bunch of headaches
A post was split to a new topic: Self-Hosting git, CI
You misunderstood lol, I am not saying self host. I am saying use Codeberg / Gitea as in they offer free instances.
What does this have to do with phabricator? What benefit does that give the team over using github? What about our existing CI?
We have git taken care of
More and more tickets are completely unreadable. So to get the data out, we might have to migrate to Phorge first.
Mediawiki uses Phorge:
Since 2023-08-23, we actually use the Phorge fork of Phabricator (T333885), but we have not (yet?) started to update references to the old software name.
Done.
https://phabricator.whonix.org/
Is now based on Phorge. All bugs of unreadable tickets seem to be fixed.
That’s also just a “temporary” solution. The to complete the following is still the goal:
So would a programmatic import of the issues to discourse solve the problem?
To do this I would need an API key to discourse, with permissions to post a lot of topics. I also would need a phorge API key.
Then just write a script to pull the issues from phabricator, format them, post to discourse.
At that point, we could turn off phabricator and remove it from the server
cc @Patrick
Yes.
Before the migration I found some dashboard spam (for which I didn’t get e-mail notifications) that should be deleted before migration. Since there’s no delete button even for admins in the phabricator web interface needed more than 1 hour to figure out how do delete it.
https://phabricator.whonix.org/dashboard/view/2/ the 2 needs to be used in a mysql query:
SELECT phid FROM phabricator_dashboard.dashboard WHERE id = 8;
And then delete it:
/var/phabricator/phabricator/bin/remove destroy PHID-DSHB-tzk4o6etocjf4e6i6mqu
Migration as it is currently written should only migrate issues in maniphest, not “dashboards”