1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
---
title: DIY an offline bug tracker with text files, Git and email
date: 2020-11-07
updated_at: 2021-08-14
layout: post
lang: en
ref: diy-an-offline-bug-tracker-with-text-files-git-and-email
---
When [push comes to shove][youtube-dl-takedown-notice], the operational aspects
of governance of a software project matter a lot. And everybody likes to chime
in with their alternative of how to avoid single points of failure in project
governance, just like I'm doing right now.
The most valuable assets of a project are:
1. source code
2. discussions
3. documentation
4. builds
5. tasks and bugs
For **source code**, Git and other DVCS solve that already: everybody gets a
full copy of the entire source code.
If your code forge is compromised, moving it to a new one takes a couple of
minutes, if there isn't a secondary remote serving as mirror already. In this
case, no action is required.
If you're having your **discussions** by email,
"[taking this archive somewhere else and carrying on is effortless][sourcehut-ml]".
Besides, make sure to backup archives of past discussions so that the history is
also preserved when this migration happens.
The **documentation** should
[live inside the repository itself][writethedocs-in-repo][^writethedocs-in-repo],
so that not only it gets first class treatment, but also gets distributed to
everybody too. Migrating the code to a new forge already migrates the
documentation with it.
[^writethedocs-in-repo]: Described as "the ultimate marriage of the two". Starts
at time 31:50.
As long as you keep the **builds** vendor neutral, the migration should only
involve adapting how you call your `tests.sh` from the format of
`provider-1.yml` uses to the format that `provider-2.yml` accepts.
It isn't valuable to carry the build history with the project, as this data
quickly decays in value as weeks and months go by, but for simple text logs
[using Git notes] may be just enough, and they would be replicated with the rest
of the repository.
[using Git notes]: {% link _tils/2020-11-30-storing-ci-data-on-git-notes.md %}
But for **tasks and bugs** many rely on a vendor-specific service, where you
register and manage those issues via a web browser. Some provide an
[interface for interacting via email][todos-srht-email] or an API for
[bridging local bugs with vendor-specific services][git-bug-bridges]. But
they're all layers around the service, that disguises it as being a central
point of failure, which when compromised would lead to data loss. When push comes
to shove, you'd loose data.
[youtube-dl-takedown-notice]: https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md
[sourcehut-ml]: https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-censorship/
[writethedocs-in-repo]: https://podcast.writethedocs.org/2017/01/25/episode-3-trends/
[todos-srht-email]: https://man.sr.ht/todo.sr.ht/#email-access
[git-bug-bridges]: https://github.com/MichaelMure/git-bug#bridges
## Alternative: text files, Git and email
Why not do the same as documentation, and move tasks and bugs into the
repository itself?
It requires no extra tool to be installed, and fits right in the already
existing workflow for source code and documentation.
I like to keep a [`TODOs.md`] file at the repository top-level, with
two relevant sections: "tasks" and "bugs". Then when building the documentation
I'll just [generate an HTML file from it], and [publish] it alongside the static
website. All that is done on the main branch.
Any issues discussions are done in the mailing list, and a reference to a
discussion could be added to the ticket itself later on. External contributors
can file tickets by sending a patch.
The good thing about this solution is that it works for 99% of projects out
there.
For the other 1%, having Fossil's "[tickets][fossil-tickets]" could be an
alternative, but you may not want to migrate your project to Fossil to get those
niceties.
Even though I keep a `TODOs.md` file on the main branch, you can have a `tasks`
branch with a `task-n.md` file for each task, or any other way you like.
These tools are familiar enough that you can adjust it to fit your workflow.
[`TODOs.md`]: https://euandre.org/git/remembering/tree/TODOs.md?id=3f727802cb73ab7aa139ca52e729fd106ea916d0
[generate an HTML file from it]: https://euandre.org/git/remembering/tree/aux/workflow/TODOs.sh?id=3f727802cb73ab7aa139ca52e729fd106ea916d0
[publish]: https://euandreh.xyz/remembering/TODOs.html
[fossil-tickets]: https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki
|
