Author: intrigeri Date: To: Tails localization discussion Subject: Re: [Tails-l10n] Decide what to do with documentation about very
old migrations
sajolida wrote (24 Jun 2016 15:01:43 GMT) : > 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.
OK, got it. Thanks! Just to be clear: leaving the doc and migration
code in place does not guarantee it'll still be working, so it seems
that the proposal is to leave them in place and hope they still work,
without taking active steps to make sure that use case is supported
(e.g. porting to / testing on Stretch), right? If so, I can very well
live with that proposal.
> I didn't think hard enough about /doc/first_steps/persistence/upgrade to
> know if the same reasoning can happen.
I have my doubts that it still works, given how much time has passed
since then, but who knows :)
> 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.
I see. I'm fine with generalizations as long as we're aware there will
be exceptions, hence your "ideally" :)
> 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.
This could work. I would include in "problematic" the case when the
fact that the old migration code is still in place requires us to do
more work when working on something else: it doesn't make sense to me
to pay such maintenance costs for code+doc that nobody has bothered
testing for ages, and that will stop working sooner or later without
anyone realizing in due time.
(And I'll shut up about "having more code to take into account" being
a problem in itself ;)
