Moving Primary Development off Github

[baetheus]

Hello All,

I've been wanting to move the primary development repository off github for awhile. I've been stymied by the lack of standardization for ticketing and documentation (wiki) associated with the various self-hosted git solutions (I looked at gitea, gitlab, and gitweb). They all worked but either they lacked some feature I wanted or disaster recovery was convoluted when I tried it.

Ultimately, I've settled on fossil. I've already started doing primary development on a hosted fossil instance at code.null.pub and even wrote a decent nix module for fossil that I'll look into contributing to nixpkgs at some point.

I know that this creates a burden for contributors to fun, namely that they have to install fossil and learn the handful of commands for branching/committing. For that I'm sorry. It is my hope that in the long term this ends up being a good move.

I've already tested exporting to github and it works fine. I'll be setting up a cron job on the server to do nightly exports from code.null.pub to github once I'm closer to the 2.0 release.

If you aren't put off by the change and still want to contribute check out the fossli getting started documentation. I'll need to add you as a contributor to the repository so be sure to reach out as well.

Thanks!

[baoshan]

Thanks very much for letting us know the details.

I’m unsure if the reason is more about controversial topics such as Copilot or more about a local-first & self-contained VCS/ticket/wiki experience. I don’t know Fossil, but I do wish this decision will bring benefits in the long term.

Anyway, I’ll ping you when I have the required judgment, opinion, time, and taste to contribute to fun.

BTW: does Fossil expose a URL that can be used in an import_map.json file like raw.githubusercontent.com?

[pixeleet]

You're moving at light speed :D I'm happy to contribute, wherever the project lives

[baetheus]

@baoshan After a little searching I did find links to the raw files. There are two issues with these links, however.

1. They are not easy to reference via code. See this
2. The response headers are not ideal for consumption via Deno, see:

brandon@rosalind % curl -I 'https://code.null.pub/fun/raw/7fe62cfacad51a02d56ab4cc38d4a8779bb6a15abdba51148ca8edcc468ce963?at=7fe62cfaca'                                                                                                       ~/src/fun/main
HTTP/2 200 
server: nginx
date: Sun, 16 Oct 2022 19:36:05 GMT
content-type: application/x-fossil-artifact
content-length: 26001
cache-control: max-age=315360000, immutable
content-security-policy: default-src 'self' data:; script-src 'self' 'nonce-452006accdd1fd4c9395a6661e99b632a1851d99eb64621d'; style-src 'self' 'unsafe-inline'; img-src * data:
content-disposition: attachment; filename="7fe62cfaca";
x-frame-options: SAMEORIGIN

The content-type is `application/x-fossil-artifact', which Deno will hang on:

error: Expected a JavaScript or TypeScript module, but identified a Unknown module. Importing these types of modules is currently not supported.
  Specifier: https://code.null.pub/fun/raw/7fe62cfacad51a02d56ab4cc38d4a8779bb6a15abdba51148ca8edcc468ce963?at=7fe62cfaca
    at file:///Users/brandon/src/fun/main/examples/test.ts:1:20

I could setup a mirror on the same server, but honestly I think it is prudent to keep a runtime dependency (import source) separate from the primary repository mirror that I use for development.

However, here are a few solutions for you:

1. Continue pulling from github.com/baetheus/fun. I will not be removing this repository, I'll continue to export the fossil repo to it manually for now and in the future I'll setup either a nightly or weekly export from code.null.pub that will do it automatically.
2. Start pulling from deno.land/x/fun. I've pushed a v2.0.0-alpha.0 tag to the github repo, which has been replicated to deno.land. This is actually my preferred method for using the fun lib, since the deno.land/x paths are immutable, meaning imports from there should always result in the same code being referenced.

Hope this helps!

[baetheus]

@baoshan My reasons for moving off of GitHub are varied, but I don't think they are controversial. In no specific order they are:

1. Reliability. In a previous life I did systems administration. The services I run for myself and my friends have a much higher uptime and customer satisfaction rating than github.
2. Risk Management. I'm at a point where some of my repositories are dependencies of the services I run. The possibility (however remote) of being locked out of github or having my repos sanctioned in some way is therefore a risk to the reliability of my services.
3. Backups. I already run a fairly robust backup and disaster recovery policy on my servers, this includes incremental snapshots with copies in three countries. While it is trivial to setup a cron job to clone all of my repos onto these servers it is just as easy to run fossil and inherit the backup policy from its host.
4. Personal. In general I'm not a fan of gamification of GitHub. I also don't like the feature churn around tickets and projects. After reading and playing with fossil for a few weeks I found the cli, philosophy, and interface refreshing. That tickets, forums, wiki, and chat are all part of a single repository is just icing on that cake.

But, like I said in the previous comment. I'll be keeping my github account and will migrate my other repos to code.null.pub one at a time.

[pmartin-cogility]

Or? https://en.wikipedia.org/wiki/Shiny_object_syndrome

[baetheus]

@pmartin-cogility Was perhaps a little right. Fossil was great to use by myself but made consuming PRs and branches from contributors problematic. I've since switched back to git but use Jujutsu for developing and git push origin main when I need to push (until jj fixes the issue with interactive ssh).