Autor: sajolida Data: A: Tails localization discussion Assumpte: Re: [Tails-l10n] Decide what to do with documentation about very
old migrations
intrigeri: > 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?
Yes. And to actively remove the code and documentation if we ever get to
learn (for example, through user feedback or testing) that they stopped
working.
> If so, I can very well live with that proposal.
\o/
>> 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 :)
Yes.
>> 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.
