Decentralized Collaboration

Old School Collaboration & September 16, 2020

There's been a ton going on since my last post. Some highlights on that note:

• I finally have an upgrade for my N900, a Droid4, which is a whole work in progress that deserves its own post.
• I finally got my hands on a Pinebook Pro! Which requires a bit of manual building to get running with Alpine, and signals the renewal of KWS Chronos development, which once again, requires a whole post, probably a series.
• We're pushing for a deployment of salt across all of our businesses at Chenmark, along side a customized Alpine workstation image. Super exciting, but a lot of work.
• And finally, the point of this point, I'm collaborating on fa with my friend Jesse! We'll talk more about that below.

Right so, decentralized collaboration! What does that even mean? Well fa has recently moved from Github to Notabug, and then from Notabug to a self hosted Gitea instance! Why? Well the move from Github to Notabug was prompted by the political turmoil caused by Github's association with ICE. A lot of high profile FOSS projects migrated in a sort of software exodus over this. Fennel moved over to sr.ht for example. That doesn't really suite all of us though, so fa moved over to a self hosted Gitea instance on Jesse's website, you can find it here.

Me? I use Gitlab, and with 30 repos and counting I really am uninclined to migrate to something else. When I try and organize those repos even, all in the same space, I get lost. Plus for me, if someone wants to contribute something, they can use their Gitlab account to make an issue, or a MR. It's super nice and simple for people to contribute. But what happens when you're trying to contribute to another project, you're kind of at their whim insofar as how you collaborate goes.

When I make packages for Alpine, I have to use their Gitlab instance, which is a self hosted isolated version. I have a separate account in their Gitlab space. That enables everything, the same could be said if I wanted to contribute to Fennel I could get a sr.ht account. But I don't REALLY want to do that. I just said I couldn't keep up with my Gitlab repos, why would I want to have tons of different repos in tons of different isolated git instances, it would just get more and more confusing as I tried to do more and more. Maybe that's okay for big persistent projects like Alpine packages where everything being committed is towards a large multi-part project, but even then I have my testing repo inside of my Gitlab space.

Fortunately there is a dead simple solution to all of this, email. Git send-email lets you send patches via email to someone. No clunky JS heavy front-end, no profile on some random git instance. Nope, all you need is an email, and a copy of the repo to contribute. Perfect solution! And the configuration for it is dead simple too. Just adding a [sendemail] block to your .gitconfig will let you throw patches via email where ever you desire!

[sendemail]
        smtpserver = smtp.gmail.com
        smtpserverport = 587
        smtpencryption = tls
        smtpuser ="wpsinatra@gmail.com"
        suppresscc = self
        confirm="auto"
 

Once you .gitconfig is setup, all you need to do is make changes in your local repo, and then git send-email --to="jesselaprade@gmail.com" HEAD^ (or whatever commit you mean to cherry pick) to send your patches off.

Syncing the repo with the remote upstream is honestly dead simple too. You can simply set the main branch of the remote project to the upstream source, and git fetch/rebase it at whim. Setting that up the first time is a simple set of commands as well:

git remote add upstream https://git.m455.casa/m455/fa.git
git fetch upstream
git rebase upstream/main
 

Once you have the upstream set, and you git send-email settings enabled you can push patches via email and follow the remote repo's progress to see when the patches get merged. And once they have been a quick git fetch && rebase will sync your copy of the repo.

Dead simple, and something you could do from any system regardless of how resource deprived it is. My N900 can't handle the interface for Gitlab at all, and it can be annoying to navigate sr.ht via lynx at time, but if you only need access to email to send patches, and you already happen to be okay using CLI systems like git, or mutt, then this will fit in super well with your workflow. It works out excellently for Jesse and I! It's a tried and true method, even if all you can provide someone is a read-only https clone git instance, you can still collaborate with them. Even if they're on a different git instance, or if Github, Gitlab, sr.ht, Sourceforge, and all the rest disappear tomorrow, you can still spin up a Gitea instance, or cgit, or hell provide source repos in tarballs on a web server. As long as people can pull down the source code to a local repo, they can collaborate and send changes upstream!

That all might be over active worry. Gitlab and Github are likely not going anywhere anytime soon, but I personally don't want to scramble to figure out how to deal with these kinds of things when they do disappear. At the end of the day if I control the hosting, then I can continue to build and provide that source to people. If they have some modicum to contribute, as long as documentation exists that they can delve into and determine how to do so, I have to hope that they will in fact do so.