<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 21/02/2011 13:53, Tanstaafl wrote:
<blockquote cite="mid:4D626E5D.7090609@libertytrek.org" type="cite">
<pre wrap="">On 2011-02-21 8:25 AM, Ludovic Hirlimann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Today I realized that we would not need the migration was obsolete. We
have EOLed 3.0 and 2.x for more than six month. We've been pushing 3.1.x
to our users on 2.x. More than 80% of our 2.x users have migrated to
3.1. I don't think we'll need the assistant when we release the next
version of Thunderbird. So I would like the code for the migration
assistant to be removed.
</pre>
</blockquote>
<pre wrap="">
Is the code causing problems? I would say don't remove it for at least
another year or so unless there is a very good reason.
</pre>
</blockquote>
The code to install the add-ons is currently broken which is what
has raise the question. At a quick glance it is probably reasonably
easy to fix.<br>
<br>
Can you explain why you think we shouldn't remove it?<br>
<br>
My reasoning runs like this:<br>
<ul>
<li>We've now got the majority of users on 3.1.</li>
<li>Although we published major updates for both 2.x and 3.0.x
users to 3.1.x, that is actually non-standard. When it comes to
3.3 we will only offer major updates to 3.1 users.</li>
<li>So the recommended update route for users will be 2.0.x (or
3.0.x) -> 3.1.x -> 3.3.x</li>
<li>There may obviously be some users who jump from 2.0.x/3.0.x to
3.3.x by installing Thunderbird from scratch, but I suspect they
will be in the minority.</li>
<li>We're not expecting to need a migration assistant for 3.1
-> 3.3 users. If we did, I would expect to scrap all of the
existing settings (because users on 3.1 wouldn't need/want to go
through them again) and start from scratch.<br>
</li>
<li>Therefore the migration assistant in 3.3 is likely to be
largely dead code that we're paying a price to maintain.<br>
</li>
</ul>
That price is small at the moment, however, we do also need to
consider that this is something that we don't have extensive
automated tests for and we're potentially going to break without
noticing (iirc the existing bug went for a couple of months before
getting reported).<br>
<br>
I'm open to suggestions on this, if there is benefit, then we can
keep it, but I think we should also be setting a timescale for
removal.<br>
<br>
Mark.<br>
</body>
</html>