Written by ziroday the 14 Jan 09 at 11:50.

Before upgrading a system have a dialog box warning the user about regressions and a large link to the release notes so that they can check for any identified regressions against their hardware. It should also contain information on how to view what hardware you currently have (possibly through hardinfo or something similar).

Before upgrading a system have a dialog box warning the user about regressions and a large link to the release notes so that they can check for any identified regressions against their hardware. It should also contain information on how to view what hardware you currently have (possibly through hardinfo or something similar).

Written by Seph_VII the 14 Jan 09 at 21:14.

Before upgrading or installing Ubuntu, make it check an online(or on-cd, if installing from a LiveCD) blacklist of incompatible hardware. If incompatible hardware is found, make Ubuntu warn the user, and ask whether he/she still wants to continue.

Before upgrading or installing Ubuntu, make it check an online(or on-cd, if installing from a LiveCD) blacklist of incompatible hardware. If incompatible hardware is found, make Ubuntu warn the user, and ask whether he/she still wants to continue.

Written by ruben the 26 Jan 09 at 21:09.

The function i have in mind is a simple undo of an update or even a package installation.
Unlike apt-get --perge remove it would also delete any unneaded dependancies simmilar to autoremove. However this would make it possible to install updates and then if it didn't work undo the change. Including any movement of files or changes in other files.

The problem i see with an upgrade advisor is that it can never actually say if it will work as only trial and error can. Or at least in most cases. Also it is very possible that the upgrade advisor does not have all the correct information for all systems and thus advises incorrectly. Furthermore advice given need to be based on information gather beforehand. Thus an easy undo feature would make upgrading a lot less risky.

It would be even better if this feature could some how be accessed from recovery mode or a live cd to repair if the system was rendered unboot able. This feature should be a used in conjunction with an upgrade advisor. Perhaps more as a long run solution

The function i have in mind is a simple undo of an update or even a package installation. Unlike apt-get --perge remove it would also delete any unneaded dependancies simmilar to autoremove. However this would make it possible to install updates and then if it didn't work undo the change. Including any movement of files or changes in other files. The problem i see with an upgrade advisor is that it can never actually say if it will work as only trial and error can. Or at least in most cases. Also it is very possible that the upgrade advisor does not have all the correct information for all systems and thus advises incorrectly. Furthermore advice given need to be based on information gather beforehand. Thus an easy undo feature would make upgrading a lot less risky. It would be even better if this feature could some how be accessed from recovery mode or a live cd to repair if the system was rendered unboot able. This feature should be a used in conjunction with an upgrade advisor. Perhaps more as a long run solution

Written by torkiano the 30 Jan 09 at 20:45.

Smolt is a hardware profiler to enable users to submit their hardware profiles during installation.

Smolt, like PackageKit from Fedora is also a distribution neutral tool and collects stats anonymously and sends it to a central database.

It became clear quite quickly that it does not make sense to have a per-distro solution for that - if we want to have momentum with a hardware database a combined effort promises the most.

Fedora and Opensuse already implemented it.

See http://smolts.org/
http://www.osnews.com/story/20621/Smolt_gets_adopted_by_openSUSE

Smolt is a hardware profiler to enable users to submit their hardware profiles during installation. Smolt, like PackageKit from Fedora is also a distribution neutral tool and collects stats anonymously and sends it to a central database. It became clear quite quickly that it does not make sense to have a per-distro solution for that - if we want to have momentum with a hardware database a combined effort promises the most. Fedora and Opensuse already implemented it. See http://smolts.org/ http://www.osnews.com/story/20621/Smolt_gets_adopted_by_openSUSE

Written by Felix_the_Mac the 29 Feb 08 at 23:16.

Update Manager should analyse the dependencies in packages which need updating and download the packages with no dependencies first (that is no dependencies on packages which themselves need updating), followed by files which only depended on the first package downloaded etc.

This will allow updates to be installed in parallel - as soon as the first package is downloaded it can be installed.

Update Manager should analyse the dependencies in packages which need updating and download the packages with no dependencies first (that is no dependencies on packages which themselves need updating), followed by files which only depended on the first package downloaded etc. This will allow updates to be installed in parallel - as soon as the first package is downloaded it can be installed.

Written by xfuser4 the 21 Aug 09 at 06:16.

After kernel updates, we are asked for restarting the computer. If a (critical) update of an application have happened, the update manager should ask for an restart of the application (or inform the user about the need of a restart).

After kernel updates, we are asked for restarting the computer. If a (critical) update of an application have happened, the update manager should ask for an restart of the application (or inform the user about the need of a restart).

Written by germclown the 24 Aug 09 at 05:30.

If 1 or more critical updates have been installed, we are offered a checklist of all apps that will benefit from a restart. The dialogue makes clear that all listed apps will benefit from a restart (and maybe how) and that all checked apps will be automatically restarted with an attempt made to return the app to its previous state (subject to security or other important concerns). Examples: Transmission torrents return to their individual active/paused status, Pidgin either remains unlogged or autologs the last user, active OpenOffice docs are reopened.

Updater preferences allow the user to choose which update types appear on the checklist: "security", "bug fix", "new feature"

If 1 or more critical updates have been installed, we are offered a checklist of all apps that will benefit from a restart. The dialogue makes clear that all listed apps will benefit from a restart (and maybe how) and that all checked apps will be automatically restarted with an attempt made to return the app to its previous state (subject to security or other important concerns). Examples: Transmission torrents return to their individual active/paused status, Pidgin either remains unlogged or autologs the last user, active OpenOffice docs are reopened. Updater preferences allow the user to choose which update types appear on the checklist: "security", "bug fix", "new feature"

Written by lavinog the 31 Aug 09 at 17:07.

Annoying users with restart notices can deter users from updating in a timely manner.
To avoid displaying excessive restart prompts, the prompts should be displayed after a preset time if the application hasn't been restarted since the update.
User A was only going to be using pidgin for 20 minutes, he shouldn't be interrupted by a dialog asking him to put his conversation on hold for a restart.
User B performs updates, but leaves his computer idle for a couple of hours. When he comes back to his computer, he will see a dialog box explaining that the recent security update wont take affect until the application is restarted.

Annoying users with restart notices can deter users from updating in a timely manner. To avoid displaying excessive restart prompts, the prompts should be displayed after a preset time if the application hasn't been restarted since the update. User A was only going to be using pidgin for 20 minutes, he shouldn't be interrupted by a dialog asking him to put his conversation on hold for a restart. User B performs updates, but leaves his computer idle for a couple of hours. When he comes back to his computer, he will see a dialog box explaining that the recent security update wont take affect until the application is restarted.

Written by natureflow the 3 Sep 09 at 10:29.

I propose to update the application "on-fly". So you don't need to stop chatting if your instant messenger gets an update.

I propose to update the application "on-fly". So you don't need to stop chatting if your instant messenger gets an update.

Written by adisk the 16 Sep 09 at 15:18.

Show restart indicator in tray.
Click on indicator show question for restart.

Show restart indicator in tray. Click on indicator show question for restart.

Written by adisk the 16 Sep 09 at 15:40.

Send email notification to admin. For servers only.

Send email notification to admin. For servers only.

Written by kritzikratzi the 14 Oct 09 at 13:56.

like #5, but when the "restart-indicator" is clicked it folds down to a list, the top entry saying
"some of your applications received important updates, but need to be restarted before these can take effect".

after that a list of applications in question and a "restart all" item follow.

if the user clicks on one of the apps it is restartet and disappears from the list.
if an app was manually restartet (by the user) it also disappears from the list.
if there are no more apps left the restart-indicator should close by itself.

sometimes system components receive updates which will only take effect after a full reboot. this can be incorporated by adding an item to the very bottom that says "In fact there are some udpates which require to restart the entire operating system. Restart now! "

like #5, but when the "restart-indicator" is clicked it folds down to a list, the top entry saying "some of your applications received important updates, but need to be restarted before these can take effect". after that a list of applications in question and a "restart all" item follow. if the user clicks on one of the apps it is restartet and disappears from the list. if an app was manually restartet (by the user) it also disappears from the list. if there are no more apps left the restart-indicator should close by itself. sometimes system components receive updates which will only take effect after a full reboot. this can be incorporated by adding an item to the very bottom that says "In fact there are some udpates which require to restart the entire operating system. Restart now! " <img src="http://img390.imageshack.us/img390/5393/ubunturestartnotify.png">

Written by slsolaris the 8 Oct 08 at 03:24.

Ubuntu Brainstorm was updated in January 2009. Since the idea #14205 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #14205 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by hspaans the 13 Jul 08 at 15:56.

Ubuntu Brainstorm was updated in January 2009. Since the idea #11085 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #11085 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!

Written by michel.alexander the 7 Mar 09 at 13:24.

Maybe it is possible to integrate a backup-software (suggestions? - there are so many existing) into the live-installer and the update progress of the update-manager.

Maybe it is possible to integrate a backup-software (suggestions? - there are so many existing) into the live-installer and the update progress of the update-manager.

Written by ubunteando1 the 12 Mar 09 at 21:21.

When you go to update Ubuntu create an automatically partition and save the data there and clear this partition (automatically) when the ubuntu instalation have finish

When you go to update Ubuntu create an automatically partition and save the data there and clear this partition (automatically) when the ubuntu instalation have finish

Written by OpenNingia the 16 Mar 09 at 09:52.

When Ubuntu automagically configures your partition table, should at least detect already existing /home partitions, because if you want to do a fresh install from CD but already had linux ( Ubuntu ) installed in that disk, you must use manual partition option to not lose your /home partition :/

When Ubuntu automagically configures your partition table, should at least detect already existing /home partitions, because if you want to do a fresh install from CD but already had linux ( Ubuntu ) installed in that disk, you must use manual partition option to not lose your /home partition :/

Written by jv13613 the 12 Oct 10 at 22:58.

Use the Ksplice software and service in a default install of ubuntu.

Use the Ksplice software and service in a default install of ubuntu.

Written by jv13613 the 12 Oct 10 at 23:01.

Instead of Ksplice, Inc. providing updates, have Canonical provide them. (Ksplice does not provide server kernel updates for free. Canonical may be able to provide them for free.) The ksplice software will still be used, but not the update service from Ksplice Inc. The software and service by Canonical will be installed by default.

Instead of Ksplice, Inc. providing updates, have Canonical provide them. (Ksplice does not provide server kernel updates for free. Canonical may be able to provide them for free.) The ksplice software will still be used, but not the update service from Ksplice Inc. The software and service by Canonical will be installed by default.

Written by jv13613 the 12 Oct 10 at 23:09.

Instead of having to use 2 update managers, integrate ksplice into the existing update manager. This will allow you to manage kernel updates and package updates in the same manager. (using solution 1 or 2)

Instead of having to use 2 update managers, integrate ksplice into the existing update manager. This will allow you to manage kernel updates and package updates in the same manager. (using solution 1 or 2)

Written by qwerty800 the 4 Jun 09 at 20:33.

In a world where softwares are very often abandonned because of a lack of motivation from the developpers, having an update every 6 month that completely changes the repositories is not a good idea.

We should at least keep some old packages (or make them redirect to newer ones) so that we can still use all of these abandoned softwares.

In a world where softwares are very often abandonned because of a lack of motivation from the developpers, having an update every 6 month that completely changes the repositories is not a good idea. We should at least keep some old packages (or make them redirect to newer ones) so that we can still use all of these abandoned softwares.

Written by Shady3D the 6 Jun 09 at 07:45.

the package manager will be cluttered with versions by adding older versions too, so just make another channel for it, so if someone wants it, just add the URL of the old repository.

the package manager will be cluttered with versions by adding older versions too, so just make another channel for it, so if someone wants it, just add the URL of the old repository.

Written by rakudave the 6 Jun 09 at 10:47.

Have a page where all abandoned projects are listed and where people can sign up to take over the maintenance of such a project.

Have a page where all abandoned projects are listed and where people can sign up to take over the maintenance of such a project.

Written by TwistedLincoln the 6 Jun 09 at 16:09.

Why not simply add a "unsupported" repository branch along with the current main, universe, multiverse and restricted?

Then Canonical can disavow the packages, yet still provide easy access to those that need them.

Why not simply add a "unsupported" repository branch along with the current main, universe, multiverse and restricted? Then Canonical can disavow the packages, yet still provide easy access to those that need them.

Written by kurtedelbrock the 14 Jun 09 at 01:51.

If you are already using the software, moving it to an "unsupported" repository branch won't do much good. Why not have bloggers who specialize in Ubuntu applications make a quick announcement, and get it on sites such as The Daily Ubuntu or LXer?

If you are already using the software, moving it to an "unsupported" repository branch won't do much good. Why not have bloggers who specialize in Ubuntu applications make a quick announcement, and get it on sites such as <a href="http://thedailyubuntu.blogspot.com/">The Daily Ubuntu</a> or <a href="http://lxer.com">LXer</a>?

Written by ludovicc the 16 Jun 09 at 22:59.

In the package description in Synaptic, link the package to a donation page that you could create on fossfactory.org for example. Then update the package description in Ubuntu (requires some very minimal packaging skills).

The idea is that users of the package will look for more information about that package using the tools provided by Ubuntu, such as Synaptic, then be redirected to a donation site for that project. With enough donations, more developers can be attracted and revive the project.

In the package description in Synaptic, link the package to a donation page that you could create on fossfactory.org for example. Then update the package description in Ubuntu (requires some very minimal packaging skills). The idea is that users of the package will look for more information about that package using the tools provided by Ubuntu, such as Synaptic, then be redirected to a donation site for that project. With enough donations, more developers can be attracted and revive the project.

Written by krycek the 16 Oct 09 at 12:56.

Imagine that packages could be generate just once and be used in future releases without any extra work.

That would reduce significantly the work necessary by canonical developers for every release, since they could use the existing packages that weren't changed.

Users would be allow to use "unsupported" applications too.

That's not an easy solution, I know, but it is the one that has more benefits of all. In the long term, it would help all people involved.

Imagine that packages could be generate just once and be used in future releases without any extra work. That would reduce significantly the work necessary by canonical developers for every release, since they could use the existing packages that weren't changed. Users would be allow to use "unsupported" applications too. That's not an easy solution, I know, but it is the one that has more benefits of all. In the long term, it would help all people involved.

Written by TommyGee the 27 Feb 09 at 17:10.

A easy-to-read changelog after updates via Synaptic/Adept maybe only with "new things" in standard message and "dev related changes" in an "advanced" message that you can choose by clicking on a "advanced" button.

A easy-to-read changelog after updates via Synaptic/Adept maybe only with "new things" in standard message and "dev related changes" in an "advanced" message that you can choose by clicking on a "advanced" button.

Written by aikiwolfie the 13 Aug 08 at 12:32.

Ubuntu Brainstorm was updated in January 2009. Since the idea #12168 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

<i>Ubuntu Brainstorm was updated in January 2009. Since the idea #12168 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution.</i><br /> Thanks!