Add post: Off of github

1 files changed, 72 insertions, 0 deletions

diff --git a/content/blog/2018-06-10-off-of-github.md b/content/blog/2018-06-10-off-of-github.md
new file mode 100644
index 0000000..39719c3
--- /dev/null
+++ b/content/blog/2018-06-10-off-of-github.md
@@ -0,0 +1,72 @@
+---
+title: "Off of github!"
+date: "2018-06-10T11:42:06"
+tags: [ "open source", "imag" ]
+---
+
+Microsoft aquired Github. I'm not here to judge on the decision of the github
+leadership to let Microsoft buy Github.
+As a result, though, the imag project will move away from github.
+Also, all other Rust projects that were initialized because of a requirement
+of imag, will be moved to the imag project site as well.
+That is: task-hookrs, filters, is-match, kairos and toml-query. So the
+following applies to those as well.
+
+
+# Moving
+
+As I'm on a sabatical right now, I cannot do this _now_. But as soon as I'm
+home and have the appropriate amount of time, I will be moving to my own
+infrastructure with everything (that is: code, issues and PR discussions and
+CI).
+
+
+# Issues and other metadata
+
+Issues and PR metadata from the github repository/repositories are be backed up.
+We did not
+decide yet whether we will import them into another tool like gitea or
+phabricator or even git-dit (which would be the top-prio for me, personally).
+
+As not everyone would want to use git-dit for submitting issues, the
+mailinglist would be the way to go and I would maintain the git-dit repository
+on my own then.
+This is not that much of an issue for me. If the volume increases, others
+could add issues to dedicated issue tracker repositories on the gitolite
+instance we run and I can merge them (that's the whole point of git-dit).
+An email-dit-bridge does not exist yet.
+
+
+# How we will go on
+
+What we (I) did decide: We will continue development on the mailinglist. Yes,
+this increases the hurdle for contributions quite a bit. But it is the
+cheapest and easiest way for the project.
+
+
+## How to send patches
+
+Patches should be filed via `git format-patch` and `git send-email`. If
+someone wants to dive in deeper then a patch every now and then, they can get
+a gitolite repository for the repository they are contributing to and are
+welcome to send `git request-pull` emails for branches.
+
+
+## What about CI
+
+We have no CI for the project without github. This is the one critical point
+where we do not have a solution yet.
+What I am thinking of right now: I will rent a server (I want to do that as
+soon as I'm home anyways), and we'll have build jobs for patches with it - or
+only for pushed branches... I don't know how it will be.
+
+
+# Mirroring
+
+We will, though, have the repositories mirrored on github. We could also use
+the travis-CI via github, but the main development will not happen on github
+anymore. That means that filing issues via github will not be possible anymore
+and pull requests filed via github will be closed (there's a bot that helps
+with that) with a message that a `git request-pull` message should be sent to
+the imag mailinglist (for the imag project but also for the other projects).
+