Autor: sajolida Data: A: Tails localization discussion Assumpte: Re: [Tails-l10n] Decide what to do with documentation about very
old migrations
intrigeri: > I have a very hard time finding good reasons to keep these obsolete
> pages online. The ticket says:
>
>> Still it might be nice to keep them around as historical documents
>> or to support very rare cases.
>
> We have Git for that, and a Git history web browsing interface if
> needed, so we can always find the source of these pages (thankfully
> Markdown is quite readable as-in) if we ever need them — which
> I strongly doubt, I've not heard of any realistic example.
>
> So I think I would simply drop the migration code + the corresponding
> documentation after a while.
The rare cases that I'm referring to could be someone who used Tails in,
let's say 2015, with Claws Mail, then discontinued her work, and tries
to open her emails again in 2017 because she has to work on this again.
It's seems like making this possible doesn't cost us much (keeping
migration doc and code in place) while it might save tons of trouble
(basically loosing data unless they can figure out by themselves how to
do the migration) in rare cases. And Git history doesn't help here,
unless we rewrite the migration code to point to the historical ikiwiki
source but I don't think that's a good idea.
I didn't think hard enough about /doc/first_steps/persistence/upgrade to
know if the same reasoning can happen.
Ideally I would like to take a decision that could apply for all of
these pieces of codes and doc and that allow us not to have to discuss
each time for how long we want to keep them, remember to remove them,
and do the work of removing them.
My option B allows not having to do anything in the future for the doc.
But I understand that code is different. Maybe we can say that we'll
removing migration code and doc as soon as we know that they became
problematic: because they have bit rotten and don't work anymore or are
dangerous to keep for some reason. But you know better code processes
than me...