Flesh out git article.

_drafts/self_hosted_git_summary.qmd

@@ -2,9 +2,64 @@
 title: "Summary of Free Self Hosted Git Options"
 author: "James Pace"
 date: "2024/01/12"
-draft: true
 ---
 
+# Introduction
+
+A few years ago I set started setting my own self hosted
+development stack [^dev-stack-defintion] at home in Kubernetes.
+Particularly, I currently self host gitea, a server hosting apt and
+rpm repositories, a CI stack built with Tekton, and a container registry.
+This article will focus on why I chose to self host anything at all,
+why I chose to self host a git forge specifically, and why I chose
+Gitea from the different options on the market.
+
+# Why self host a git forge?
+
+Cloud hosted development stacks like Github and Gitlab are extremely popular and
+are used by a number of open source projects, individuals, and companies.
+Using Github removes a lot of friction from taking community contributions because
+it has a well understood workflow and a huge proportion of your potential contributors
+already have an account there.
+I don't have statistics to back up the claim that a number of companies use the
+hosted on the cloud version of both tools, other than the option to buy both exist,
+and there is no short of articles proclaiming the awesomeness of using B2B subscription
+SaaS products.
+
+I'm not a huge fan of putting components that are integral to our ability to do work
+on (and only on) the internet in the defence and "dirty" commercial sectors.
+24/7 good internet connectivity is not something we should assume exists in the sectors
+we want robots to operate in, and we should build our workflows with that in my mind, picking
+tools that we can bring with us.
+This neccessitates a very "Edge" focused mentality towards the cloud, which biases my perception
+towards picking tools I can self host.
+Particularly, tools I can self host on hardware that can be brought with me when I can't assume
+24/7 connectivity.
+My original goal in setting up my own development stack was to see how far I could reasonably
+build my own "Cloud on the Edge" that could be brought with me as part of a disconnected
+command center if the need arised.
+
+A git forge specifically is a very important part of a modern development stack.
+Git forges are the primary way code is shared between developers, and without
+a git forge modern software development in teams would have to radically changed.
+Git forges are more and more being used as the single source of truth for things like
+configuration management, with modern CD workflows basically boiling down to pull
+something from a git repo and do the thing in it.
+
+# Why I chose gitea?
+
+## Other Options
+
+### Gitlab
+
+### Onedev
+
+### Gerrit
+
+[^dev-stack-definition]: I'm going to use *development stack* in this article to refer to the combination
+of a place to host git repos, do code reviews, run CI/CD, and host packages, for lack of a better
+term.
+
 <!--
 Why:
 1. All sorts of programming tools support git and using git for versioning.
@@ -40,7 +95,7 @@ Onedev:
 4. Lots of little bugs that added up.
 
 gerrit:
-1. Had the bet review process
+1. Had the better review process
 2. Really easy to write custom integrations with.
 3. Felt "powerful" using it.
 4. Code display interface sucks.