|
|
#
msgid ""
msgstr ""
msgid "title: DIY an offline bug tracker with text files, Git and email"
msgstr ""
msgid "date: 2020-11-07"
msgstr ""
msgid "layout: post"
msgstr ""
msgid "lang: en"
msgstr ""
msgid "ref: diy-an-offline-bug-tracker-with-text-files-git-and-email"
msgstr ""
msgid ""
"When [push comes to "
"shove](https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md),"
" 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."
msgstr ""
msgid "The most valuable assets of a project are:"
msgstr ""
msgid "source code"
msgstr ""
msgid "discussions"
msgstr ""
msgid "documentation"
msgstr ""
msgid "builds"
msgstr ""
msgid "tasks and bugs"
msgstr ""
msgid ""
"For **source code**, Git and other DVCS solve that already: everybody gets a"
" full copy of the entire source code."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"If you're having your **discussions** by email, \"[taking this archive "
"somewhere else and carrying on is "
"effortless](https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-"
"censorship/)\"."
msgstr ""
msgid ""
"Besides, make sure to backup archives of past discussions so that the "
"history is also preserved when this migration happens."
msgstr ""
msgid ""
"The **documentation** should [live inside the repository "
"itself](https://podcast.writethedocs.org/2017/01/25/episode-3-trends/)[^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."
msgstr ""
msgid ""
"[^writethedocs-in-repo]: Described as \"the ultimate marriage of the two\". "
"Starts at time 31:50."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"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](https://man.sr.ht/todo.sr.ht/#email-"
"access) or an API for [bridging local bugs with vendor-specific "
"services](https://github.com/MichaelMure/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."
msgstr ""
msgid "Alternative: text files, Git and email"
msgstr ""
msgid ""
"Why not do the same as documentation, and move tasks and bugs into the "
"repository itself?"
msgstr ""
msgid ""
"It requires no extra tool to be installed, and fits right in the already "
"existing workflow for source code and documentation."
msgstr ""
msgid ""
"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."
msgstr ""
msgid ""
"The good thing about this solution is that it works for 99% of projects out "
"there."
msgstr ""
msgid ""
"For the other 1%, having Fossil's \"[tickets](https://fossil-"
"scm.org/home/doc/trunk/www/bugtheory.wiki)\" could be an alternative, but "
"you may not want to migrate your project to Fossil to get those niceties."
msgstr ""
msgid ""
"Even though I keep a `TODOs.org` 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."
msgstr ""
msgid ""
"These tools are familiar enough that you can adjust it to fit your workflow."
msgstr ""
msgid ""
"I like to keep a "
"[`TODOs.org`](https://euandre.org/git/mediator/tree/TODOs.org) 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](https://euandre.org/git/mediator/tree/scripts/build-"
"site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and "
"[publish](https://euandreh.xyz/mediator/TODOs.html) it alongside the static "
"website. All that is done on the main branch."
msgstr ""
#~ msgid ""
#~ "I like to keep a "
#~ "[`TODOs.org`](https://euandre.org/git/mediator/tree/TODOs.org) 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](https://euandre.org/git/mediator/tree/scripts/build-"
#~ "site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and "
#~ "[publish](https://mediator.euandreh.xyz/tasks-and-bugs.html) it alongside "
#~ "the static website. All that is done on the main branch."
#~ msgstr ""
#~ msgid ""
#~ "I like to keep a "
#~ "[`TODOs.org`](https://euandre.org/git/mediator/tree/TODOs.org?id=110c0af4ef53faf6e1ebe87905ce16766548607e)"
#~ " 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](https://euandre.org/git/mediator/tree/scripts/build-"
#~ "site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and "
#~ "[publish](https://mediator.euandreh.xyz/tasks-and-bugs.html) it alongside "
#~ "the static website. All that is done on the main branch."
#~ msgstr ""
|
