Removing the migration Assistant from trunk builds ?

[Ludovic Hirlimann]

Hi,

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.

Thoughts ?

Ludo

--
Ludovic Hirlimann MozillaMessaging QA lead
https://wiki.mozilla.org/Thunderbird:Testing
http://www.spreadthunderbird.com/aff/79/2
http://www.mozillamessaging.com/cacert.crt <- our root cert

[Tanstaafl]

On 2011-02-21 8:25 AM, Ludovic Hirlimann wrote:
> Hi,
>
> 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.

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.
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

[Wayne Mery (vn)]

On 2/21/2011 8:53 AM, Tanstaafl wrote:
> On 2011-02-21 8:25 AM, Ludovic Hirlimann wrote:
>> Hi,
>>
>> 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.
>
> 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.

that's my initial thought as well. The MA is only presented to "old
users", right? So the intrusion in minimal.

Also, I know MA has been useful to show users who haven't converted how
to adjust the cited thunderbird settings.

[Ludovic Hirlimann]

On 21/02/11 15:03, Wayne Mery (vn) wrote:
> On 2/21/2011 8:53 AM, Tanstaafl wrote:
>> On 2011-02-21 8:25 AM, Ludovic Hirlimann wrote:
>>> Hi,
>>>
>>> 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.
>>
>> 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.
>
> that's my initial thought as well. The MA is only presented to "old
> users", right? So the intrusion in minimal.
>
> Also, I know MA has been useful to show users who haven't converted
> how to adjust the cited thunderbird settings.
>

Removing it from trunk probably means the code will be present on 3.1
which we won't eol until at least 3.3 is out the door for a certain
amount of time. But I'm not in for keeping things that aren't used. It's
not used on trunk and I don't see who would use it in 3.3.

[Mark Banner]

On 21/02/2011 13:53, Tanstaafl wrote:

On 2011-02-21 8:25 AM, Ludovic Hirlimann wrote:

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.

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.

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.

Can you explain why you think we shouldn't remove it?

My reasoning runs like this:

• We've now got the majority of users on 3.1.
• 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.
• So the recommended update route for users will be 2.0.x (or 3.0.x) -> 3.1.x -> 3.3.x
• 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.
• 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.
  
• Therefore the migration assistant in 3.3 is likely to be largely dead code that we're paying a price to maintain.
  

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).

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.

Mark.

[Mark Banner]

On 21/02/2011 14:03, Wayne Mery (vn) wrote:
> Also, I know MA has been useful to show users who haven't converted
> how to adjust the cited thunderbird settings.

We should make sure that we have support articles on most (maybe all) of
those panels and that we start to point to those.

Mark.

[Jennifer Zickerman]

On 11-02-21 6:19 AM, Mark Banner wrote:
> On 21/02/2011 14:03, Wayne Mery (vn) wrote:
>> Also, I know MA has been useful to show users who haven't converted
>> how to adjust the cited thunderbird settings.
> We should make sure that we have support articles on most (maybe all) of
> those panels and that we start to point to those.

Roger that - I'll check it out.

jen.

[Tanstaafl]

On 2011-02-21 9:16 AM, Mark Banner wrote:
> Can you explain why you think we shouldn't remove it?
>
> My reasoning runs like this:
>

> * 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.

Oh, well, if it is only being removed from trunk, which is/will be 3.3,
and 3.3. will never offer auto-updates to anything less than 3.1, that
is a stronger argument...

But again, if it isn't difficult to maintain it, then I think it should
be kept until it becomes difficult to maintain it... otherwise, removing
it makes more sense...

My reasoning is, why remove something that is useful, even to less and
less people, if it isn't hurting anything (hurting == developer overhead)?

[Wayne Mery (vn)]

On 2/21/2011 9:16 AM, Mark Banner wrote:
> Although we published major updates for both 2.x and 3.0.x users to
> 3.1.x, that is actually non-standard

by non-standard, do you mean that we normally wouldn't do MU from 2.x to
3.1 if there is a 3.0 in the middle?

[Wayne Mery (vn)]

On 2/21/2011 12:17 PM, Tanstaafl wrote:
> My reasoning is, why remove something that is useful, even to less and
> less people, if it isn't hurting anything (hurting == developer overhead)?

But it may not be useful if there's not a major update path from v2 to v3.3.

That said, 20% of users on v2 is far from an insignificant number of
users. And, do we care if a v2 user simply installs v3.3?