<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 7/2/22 12:53, Rémi Rampin wrote:<br>
</p>
<blockquote type="cite"
cite="mid:CAMto89A2n19SraKHL9E=Qd1v69KPKa+KZudCc2M2X2ddHMJNqA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">2022-07-02 12:14 UTC-04, Jason Yundt
<a class="moz-txt-link-rfc2396E" href="mailto:jason@jasonyundt.email"><jason@jasonyundt.email></a>:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>If you still want gratis hosting, then I would
recommend <a href="https://pagure.io/" target="_blank"
moz-do-not-send="true">pagure.io</a>.</div>
</blockquote>
<div><br>
</div>
<div>Hi everyone,</div>
<div><br>
</div>
<div>I'm really loving all those open-source and
non-profit-hosted alternatives. I think however that the
"long-term" aspect is a problem. How do we make sure
software hosted outside of GitHub/GitLab (or even there)
won't be lost due to a single hard drive failure, a single
person not paying their bill, or the host losing interest
(or the author force-pushing by mistake, etc).<br>
</div>
</div>
</div>
</blockquote>
<p>Here’s something to consider: Git itself is a backup solution.
When you clone a repo, you’re creating a complete backup of its
entire commit history. In the event that a hosting provider
suddenly disappears, there will probably be at least one person
who has an up-to-date clone of the repo. This means that we only
really need to worry about the parts of a project that aren’t
stored in its repo:</p>
<ol>
<li>release assets,</li>
<li>change logs,<br>
</li>
<li>which account controls the GitHub/GitLab/whatever repo,</li>
<li>the project description,</li>
<li>issues,</li>
<li>pull requests/merge requests/patches,</li>
<li>CI logs,<br>
</li>
<li>security advisories and</li>
<li>community discussions.<br>
</li>
</ol>
<p>If you want to make sure that those things don’t disappear, then
you should make sure that they’re in your repo. If we remove from
that list everything that could reasonably be kept in the main
repo, we’re left with:</p>
<ol>
<li>release assets,</li>
<li>issues,</li>
<li>pull requests/merge requests/patches,</li>
<li>CI logs and</li>
<li>community discussions.</li>
</ol>
<p>If you’re concerned about losing any of those things, then you
can store them in a <a moz-do-not-send="true"
href="https://public-inbox.org/README.html">public-inbox</a>.
Public-inboxes are sets of Git repos that contain mailing list
archives. <a moz-do-not-send="true"
href="https://public-inbox.org/public-inbox-overview.html">Anyone
can mirror public-inboxes</a>, although, in practice, lots of
people clone the main repo, and few clone the public-inbox repos.
If you want to check out public-inbox in action, take a look at <a
moz-do-not-send="true" href="https://lore.kernel.org/">lore.kernel.org</a>.</p>
<p>Additionally, there’s <a moz-do-not-send="true"
href="https://radicle.network/">a peer-to-peer network/protocol
named Radicle</a> that stores patches (their version of pull
requests) as annotated Git tags and disseminates them throughout
the network. They plan to do something similar for comments and
issues, but I don’t think that those are implemented yet. I tried
out Radicle a while ago, and it was painful to use. I’m assuming
that things over there are still very early days.</p>
<p>There’s also <a moz-do-not-send="true"
href="https://forgefed.org/">ForgeFed</a> which would
(presumably, IDK) replicate data across multiple forges. Even if
ForgeFed doesn’t store complete backups on other forges, you would
still be able to have a pull request fork on another forge. Doing
so would decrease the chances that the repos history disappears
from the Internet (even if the repo’s original address stops
working).</p>
<p>Also, if you’re not particularly attached to Git, then you could
try <a moz-do-not-send="true"
href="https://www.fossil-scm.org/home/doc/trunk/www/index.wiki">Fossil</a>
which has built-in distributed issue tracking. I don’t know what
its equivalent of pull requests are.<br>
</p>
</body>
</html>