aboutsummaryrefslogtreecommitdiff
path: root/locale/fr/LC_MESSAGES/_articles/2020-09-06-diy-an-offline-bug-tracker-with-text-files-git-and-email.po
diff options
context:
space:
mode:
authorEuAndreh <eu@euandre.org>2020-11-07 11:43:13 -0300
committerEuAndreh <eu@euandre.org>2020-11-07 11:43:13 -0300
commit24566106aba95b3b1ee38d924e49bc0578567a42 (patch)
treeade9fef1d591a7e369995733241f3583923d74c1 /locale/fr/LC_MESSAGES/_articles/2020-09-06-diy-an-offline-bug-tracker-with-text-files-git-and-email.po
parentFix date on filename of todos.org bugs article (diff)
downloadeuandre.org-24566106aba95b3b1ee38d924e49bc0578567a42.tar.gz
euandre.org-24566106aba95b3b1ee38d924e49bc0578567a42.tar.xz
Rename translation files too
Diffstat (limited to 'locale/fr/LC_MESSAGES/_articles/2020-09-06-diy-an-offline-bug-tracker-with-text-files-git-and-email.po')
-rw-r--r--locale/fr/LC_MESSAGES/_articles/2020-09-06-diy-an-offline-bug-tracker-with-text-files-git-and-email.po176
1 files changed, 0 insertions, 176 deletions
diff --git a/locale/fr/LC_MESSAGES/_articles/2020-09-06-diy-an-offline-bug-tracker-with-text-files-git-and-email.po b/locale/fr/LC_MESSAGES/_articles/2020-09-06-diy-an-offline-bug-tracker-with-text-files-git-and-email.po
deleted file mode 100644
index c2dc12c..0000000
--- a/locale/fr/LC_MESSAGES/_articles/2020-09-06-diy-an-offline-bug-tracker-with-text-files-git-and-email.po
+++ /dev/null
@@ -1,176 +0,0 @@
-#
-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 ""
-"I like to keep a "
-"[`TODOs.org`](https://git.euandreh.xyz/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://git.euandreh.xyz/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 ""
-"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 "published: false"
-#~ msgstr ""
-
-#~ msgid ""
-#~ "I like to keep a "
-#~ "[`TODOs.org`](https://git.euandreh.xyz/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://git.euandreh.xyz/mediator/tree/scripts/build-"
-#~ "site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and "
-#~ "[publish](https://mediator.euandreh.xyz/tasks-and-bugs.html) it alonside the"
-#~ " static website. All that is done on the main branch."
-#~ msgstr ""
-
-#~ msgid ""
-#~ "Even though I keep a `TODOs.org` file on the main branch, you may pick any "
-#~ "name you like, or use a dedicated branch just for that, split tasks and bugs"
-#~ " into different files, or have one file for each."
-#~ msgstr ""
-
-#~ msgid ""
-#~ "These tools are familliar enough that you can adjust it to fit your "
-#~ "workflow."
-#~ msgstr ""