Support ends dialog should auto-detect universe

[Michael Vogt]

Binary package hint: update-manager

> *Support ended dialog*
> This dialog says "If you have not enabled community maintained software
> (universe), these packages will be suggested for removal at the end of
> the upgrade.". But surely it can *tell* if you have Universe enabled? It
> should detect that and then act appropriately.

Nothing to add :) u-m should be smarter here.

[Michael Vogt (mvo)]

It should also detect (and not display) automatic install and obsoleted packages and packages we are going to remove anyway.

[Michael Vogt (mvo)]

The detection/supression of automatic installed packages in the support-ended dialog is commited as r1662.

[Mark Shuttleworth (sabdfl)]

I think we want to differentiate between packages which are already
present that are obsolete when the upgrade starts (those might be things
the user has manually installed, which we should not uninstall) and
those which are obsoleted by virtue of the upgrade (i.e. they were there
in Karmic but not in Lucid). The latter things are decisions *we* took,
so we can just uninstall them. The former things are decisions *they*
took, so we could ask about those.

Mark

[Michael Vogt (mvo)]

This is fixed in bzr now and will be part of the next upload. It will display a different text depending on if universe is enabled or not. As for your comments in #3 - this is how we do it currently, packages that were obsolete before are not touched. Packages that become obsolete during the upgrade will be removed.

This leaves the gray area of packages that are demoted to universe but not removed from the archive. Historically we have kept them on the users system if the user has universe enabled (most have) to not disrupt the users habits.

This is a tricky area because e.g. when we move from gthumb (that is in universe now) to f-spot in the default install and would remove gthumb from the users system, then f-spot will not know how to import the gthumb catalogs, folders, bookmarks etc. So the user will have a new photo management application without photos. Depending on how technical he/she is,that can be a scary experience because he will not know if the photos are gone as well. So he needs to setup f-spot in the way he wants (import folders, etc) or manually go to software-center and get it back.

[Mark Shuttleworth (sabdfl)]

On 25/02/10 16:16, Michael Vogt wrote:
> This is fixed in bzr now and will be part of the next upload. It will
> display a different text depending on if universe is enabled or not. As
> for your comments in #3 - this is how we do it currently, packages that
> were obsolete before are not touched. Packages that become obsolete
> during the upgrade will be removed.
>
> This leaves the gray area of packages that are demoted to universe but
> not removed from the archive. Historically we have kept them on the
> users system if the user has universe enabled (most have) to not disrupt
> the users habits.
>

I think the key question is whether they were in main and installed by
default, or just in main. If they were installed by default, then we
should remove them. If they were not installed by default, then leave
them because they were clearly selected by the user.

> This is a tricky area because e.g. when we move from gthumb (that is in
> universe now) to f-spot in the default install and would remove gthumb
> from the users system, then f-spot will not know how to import the
> gthumb catalogs, folders, bookmarks etc. So the user will have a new
> photo management application without photos. Depending on how technical
> he/she is,that can be a scary experience because he will not know if the
> photos are gone as well. So he needs to setup f-spot in the way he wants
> (import folders, etc) or manually go to software-center and get it back.
>

We should not switch horses without providing an upgrade script which
moves the content/bookmarks/preferences/accounts.

Mark

[Michael Vogt (mvo)]

On Thu, Feb 25, 2010 at 05:40:32PM +0000, Mark Shuttleworth wrote:
> On 25/02/10 16:16, Michael Vogt wrote:
> > This is fixed in bzr now and will be part of the next upload. It will
> > display a different text depending on if universe is enabled or not. As
> > for your comments in #3 - this is how we do it currently, packages that
> > were obsolete before are not touched. Packages that become obsolete
> > during the upgrade will be removed.
> >
> > This leaves the gray area of packages that are demoted to universe but
> > not removed from the archive. Historically we have kept them on the
> > users system if the user has universe enabled (most have) to not disrupt
> > the users habits.
> >
>
> I think the key question is whether they were in main and installed by
> default, or just in main. If they were installed by default, then we
> should remove them. If they were not installed by default, then leave
> them because they were clearly selected by the user.

Yes, I think this is a good policy.

> > This is a tricky area because e.g. when we move from gthumb (that is in
> > universe now) to f-spot in the default install and would remove gthumb
> > from the users system, then f-spot will not know how to import the
> > gthumb catalogs, folders, bookmarks etc. So the user will have a new
> > photo management application without photos. Depending on how technical
> > he/she is,that can be a scary experience because he will not know if the
> > photos are gone as well. So he needs to setup f-spot in the way he wants
> > (import folders, etc) or manually go to software-center and get it back.
> >
>
> We should not switch horses without providing an upgrade script which
> moves the content/bookmarks/preferences/accounts.

We have been lax in the past about ensuring that. Or even that they
are on par when it comes to features. To stress the gthumb -> f-spot
example again, gthumb can play videos, f-spot can not. Of course this
kind of switch is the exception.

But I agree of course that we shouldn't bother the user with the fact
that "sreadahead" is no longer in main.

This cycle we also replaced "xsane" with "simple-scan", I will enquire
to see if they have the same set of features and if there is a upgrade
route (or if we need one).

To me it sounds like the way forward is:
- show a slideshow to communicate when existing apps get replaced

- ditch support-ended dialog in GUI mode entirely
*or*
- show only "high level" apps in the GUI support ended dialog (and
  find a reliable way to identify them)
*or*
- fold the "support ended" dialog into the "Are you ready to rock"^W
  "Do you want to start the the upgrade?" dialog as one more item
  that goes into the "details"

What do you think? Or would you prefer me to contact the design team
to get input on the above questions?

Thanks,
 Michael

[Sebastien Bacher (seb128)]

> If they were installed by default, then we should remove them.

I would say the choice for those is not that easy, you often have cases where the old default software had options or features that the new one doesn't have (ie empathy doesn't do otr where pidgin does and some users have been using that for years and wouldn't understand what happens if that stopped working on upgrade without explanation). We should look at getting some better infrastructure to handle upgrades next cycle, asking users after upgrade if they want to learn about the changes in the new version and give them enough informations to take an informed decision on those

[Mark Shuttleworth (sabdfl)]

On 25/02/10 20:52, Michael Vogt wrote:
> To me it sounds like the way forward is:
> - show a slideshow to communicate when existing apps get replaced
>
> - ditch support-ended dialog in GUI mode entirely
> *or*
> - show only "high level" apps in the GUI support ended dialog (and
> find a reliable way to identify them)
> *or*
> - fold the "support ended" dialog into the "Are you ready to rock"^W
> "Do you want to start the the upgrade?" dialog as one more item
> that goes into the "details"
>

I'd go with this latter option. I would also only put in the "high
level" apps, by which I mean the things which show up in add/remove.

> What do you think? Or would you prefer me to contact the design team
> to get input on the above questions?
>

No, you can document this and ask MPT to review it.

Mark

[Mark Shuttleworth (sabdfl)]

On 25/02/10 21:04, Sebastien Bacher wrote:
>> If they were installed by default, then we should remove them.
>>
> I would say the choice for those is not that easy, you often have cases
> where the old default software had options or features that the new one
> doesn't have (ie empathy doesn't do otr where pidgin does and some users
> have been using that for years and wouldn't understand what happens if
> that stopped working on upgrade without explanation). We should look at
> getting some better infrastructure to handle upgrades next cycle, asking
> users after upgrade if they want to learn about the changes in the new
> version and give them enough informations to take an informed decision
> on those
>

We have to take responsibility for our decisions to migrate to newer
software. If we have dropped Pidgin from the default install today, we
will drop it from main tomorrow. And then the user will be running
unsupported software. We should do a damn good migration, as good as it
can be, and remove the old software. The user *can* reinstall it, but
then it is a conscious decision.

It will make switching harder, but it will make the decision more
realistic. We are fooling ourselves if we think users will just figure
this out, or love us for abandoning them on old software.

Mark

[Sebastien Bacher (seb128)]

> remove the old software. The user *can* reinstall it, but then it is a conscious decision.

there is nothing done right know to explain those changes though, $user is happily running hardy is happily using pidgin as messaging client for 2 years now and upgrade to lucid, after reboot the ui changed and talking to his friends using otr stops working. technical users might think "ok, empathy doesn't do otr, I need to install pidgin back", normal users most likely will get stucked thinking lucid is broken.

> We are fooling ourselves if we think users will just figure this out, or love us for abandoning them on old software.

Getting a perfect replacement is hard though, especially that sometime the old softwares has features we don't consider useful and don't want to put back in the new system. We should be able to inform the user though: "if you use one of this features <...> you might want to reinstall <old_software> or look for an alternative since that is not supported on $newdistro" rather than just break things under their feet silently

[Mark Shuttleworth (sabdfl)]

On 25/02/10 23:21, Sebastien Bacher wrote:
>> remove the old software. The user *can* reinstall it, but then it is a
>>
> conscious decision.
>
> there is nothing done right know to explain those changes though, $user
> is happily running hardy is happily using pidgin as messaging client for
> 2 years now and upgrade to lucid, after reboot the ui changed and
> talking to his friends using otr stops working. technical users might
> think "ok, empathy doesn't do otr, I need to install pidgin back",
> normal users most likely will get stucked thinking lucid is broken.
>

We don't install otr by default, do we? So the user installed it for
themselves? They can figure it out then.

>> We are fooling ourselves if we think users will just figure this out,
>>
> or love us for abandoning them on old software.
>
> Getting a perfect replacement is hard though, especially that sometime
> the old softwares has features we don't consider useful and don't want
> to put back in the new system. We should be able to inform the user
> though: "if you use one of this features <...> you might want to
> reinstall <old_software> or look for an alternative since that is not
> supported on $newdistro" rather than just break things under their feet
> silently
>
>
There is a tough choice to be faced. It's best for us to do the best
migration we can, for that user. If the user wants to install the old
software, fine. But if we don't do the migration, the user is going to
have to do it when their software becomes obsolete.

We absolutely should factor the cost of the migration script into the
decision.

Mark

[Michael Vogt (mvo)]

For lucid we have a improved dialog but its far from perfect. I put it on the agenda for the maverick UDS to get a properly designed solution and (maybe) a policy so that we can ensure that user-data is converted if we move e.g. from gthumb to f-spot.