Written by Afroman10496 the 6 Aug 09 at 20:15.

Totally change the interface of it to show more info, telling average users simple but important info and enhancing it with features like:

- Show the importance of the update, with colored circles or boxes showing how important it is

- Group them into tabs (according to their sub-menu in the Gnome Menu's hierarchy), like [Overview][Accessories][Games][Graphics] and so on.

- Tell the users the new features of the upgrade

- Tell the users if the update will require any restarts of anything in advance.

Totally change the interface of it to show more info, telling average users simple but important info and enhancing it with features like: - Show the importance of the update, with colored circles or boxes showing how important it is - Group them into tabs (according to their sub-menu in the Gnome Menu's hierarchy), like [Overview][Accessories][Games][Graphics] and so on. - Tell the users the new features of the upgrade - Tell the users if the update will require any restarts of anything in advance.

Written by Rodrigo the 7 Aug 09 at 16:34.

Looking at the ideas of the past days I came across one that pointed me towards this:
https://wiki.ubuntu.com/AppCenter
please have a look.
I think is a great idea.

Looking at the ideas of the past days I came across one that pointed me towards this: https://wiki.ubuntu.com/AppCenter please have a look. I think is a great idea.

Written by chrismounce the 12 Aug 09 at 23:27.

Most users don't need to know the names of all the packages that are being upgraded. It might make things look less scary if, say, all the security-related updates were lumped together into one item in the Update Manager. And not just group those updates together -- I mean *completely hide* the names of all the security-related upgrades, so the user only sees *one* security-related item in the list.

Power users should still be able to get a list of what each update contains. But regular users shouldn't be overwhelmed with 50 different package names, when all they need to know is that there's 37 MB of system upgrades, 2 MB of security patches, and a new version of Firefox.

Most users don't need to know the names of all the packages that are being upgraded. It might make things look less scary if, say, all the security-related updates were lumped together into one item in the Update Manager. And not just group those updates together -- I mean *completely hide* the names of all the security-related upgrades, so the user only sees *one* security-related item in the list. Power users should still be able to get a list of what each update contains. But regular users shouldn't be overwhelmed with 50 different package names, when all they need to know is that there's 37 MB of system upgrades, 2 MB of security patches, and a new version of Firefox.

Written by darkerego the 16 Aug 09 at 07:27.

When you go to install programs or updates, they are not in order, which could cause someone to possibly install the wrong upgrade or application that may cause problems in the future. I propose that categories should be made organize data so you can find exactly what you're looking for.

When you go to install programs or updates, they are not in order, which could cause someone to possibly install the wrong upgrade or application that may cause problems in the future. I propose that categories should be made organize data so you can find exactly what you're looking for.

Written by Penguin Guy the 16 Aug 09 at 18:18.

AppCenter is quite a neat idea, they should work on an option for that to update just before the computer shuts down rather than slowing your computer down while you're using it. This option should be disabled by default.

AppCenter is quite a neat idea, they should work on an option for that to update just before the computer shuts down rather than slowing your computer down while you're using it. This option should be disabled by default.

Written by oliver-joos the 27 Aug 09 at 23:38.

(Similar but not equal to #3!)

The Update Manager lists updatable packages. Below the list you can unfold a text field that describes what changed in the currently selected package.

I propose to group together all packages that have the very same text of changes! Each package should still be un/checkable for updating individually. But only a whole group should be selectable. Further the context menu in the list could also show "Check Group" and "Uncheck Group".

In contrast to #3 no info is hidden! I even miss the total number of updatable packages that Gutsy or Feisty once had shown.

(Similar but not equal to #3!) The Update Manager lists updatable packages. Below the list you can unfold a text field that describes what changed in the currently selected package. I propose to group together all packages that have the very same text of changes! Each package should still be un/checkable for updating individually. But only a whole group should be selectable. Further the context menu in the list could also show "Check Group" and "Uncheck Group". In contrast to #3 no info is hidden! I even miss the total number of updatable packages that Gutsy or Feisty once had shown.

Written by nave.notnilc the 30 Aug 09 at 17:09.

It is currently simple, straightforward, and concise.

It is currently simple, straightforward, and concise.

Written by LnxDeeGee the 31 Aug 09 at 01:17.

I agree that the existing system is quite poor.
I should not see so much mess in the app list. Searching for a specific app to install also should never return Beta or Source unless I've chosen to see those.

I'm 100% against AppCenter!
One of the most irritating things about Linux is all of the abandoned/orphaned/code-rot apps. How many different apps like this do we need and must we have installed?
Please do not release a different app to manage this, the source exists for the other apps, just take the best one and update it to a new version that has the required features.
There should never be multiple/duplicate/abandoned apps for the base OS... EVER!

I agree that the existing system is quite poor. I should not see so much mess in the app list. Searching for a specific app to install also should never return Beta or Source unless I've chosen to see those. I'm 100% against AppCenter! One of the most irritating things about Linux is all of the abandoned/orphaned/code-rot apps. How many different apps like this do we need and must we have installed? Please do not release a different app to manage this, the source exists for the other apps, just take the best one and update it to a new version that has the required features. There should never be multiple/duplicate/abandoned apps for the base OS... EVER!

Written by gio91ber the 16 Jan 10 at 14:42.

I think it would be a better solution to add an "Apply" button that runs the command for you, notices you of what package it will have to install/remove, asks a confirm and then applies the fix by itself...

Excuse me for my poor english...

I think it would be a better solution to add an "Apply" button that runs the command for you, notices you of what package it will have to install/remove, asks a confirm and then applies the fix by itself... Excuse me for my poor english...

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 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 Scottmoelker the 1 Aug 09 at 23:51.

Have one repository for "Ubuntu"... ie, GNOME and it's libraries, the linux kernel, core software like Add/Remove programs, system notifications, usplash, policykit etc that is maintained by Canonical. Provide maintained, independent repositories for key user software like Firefox, OpenOffice... and encourage software developers, where possible, to maintain their own "Ubuntu compatible" repository. Allow these to be linked into .deb packages, so if I download a .deb for a commercial or community program, it can install the program and also install it's repository link into Software Update for seamless, central updates for third party programs to their latest versions.

Have one repository for "Ubuntu"... ie, GNOME and it's libraries, the linux kernel, core software like Add/Remove programs, system notifications, usplash, policykit etc that is maintained by Canonical. Provide maintained, independent repositories for key user software like Firefox, OpenOffice... and encourage software developers, where possible, to maintain their own "Ubuntu compatible" repository. Allow these to be linked into .deb packages, so if I download a .deb for a commercial or community program, it can install the program and also install it's repository link into Software Update for seamless, central updates for third party programs to their latest versions.

Written by SoftwareExplorer the 4 Aug 09 at 02:01.

When a new version of Firefox came out, it got set as a different package in apt that says it's beta. New versions should be set as updates, not ignored until the next release!

When a new version of Firefox came out, it got set as a different package in apt that says it's beta. New versions should be set as updates, not ignored until the next release!

Written by sf_007 the 4 Aug 09 at 19:28.

Develop some sort of easily-installable SuperDebs, alongside with a nice "SuperDeb Creator". Just click and install! That would be cool.

Develop some sort of easily-installable <a href="http://hacktolive.org/wiki/SuperDebs">SuperDebs</a>, alongside with a nice "SuperDeb Creator". Just click and install! That would be cool.

Written by sf_007 the 4 Aug 09 at 19:39.

Why install software when you can simply run it? This would solve many problems

Why install software when you can simply run it? This would solve many problems

Written by maybeway36 the 19 Aug 09 at 15:53.

The Ubuntu backports system should contain the newest version of programs like OO.o and Firefox for each version of Ubuntu. Ideas on how to present the backports system to the user are welcome.

The Ubuntu backports system should contain the newest version of programs like OO.o and Firefox for each version of Ubuntu. Ideas on how to present the backports system to the user are welcome.

Written by xfuser4 the 29 Jun 09 at 11:24.

Presenting the user all the details of a software update could be confusing. However the user is still interested in the meaning of a certain update.

Perhaps it would be better to condense the informations somehow. Instead of telling the user the name of all 10.000 packages which are part of OpenOffice, just tell her, that an update of OpenOffice happens. Instead of giving a list of cryptic system packages, just tell, that a set of system core packages will be updated.

Esp. the initial update after the system installation is very long and confusing...

Presenting the user all the details of a software update could be confusing. However the user is still interested in the meaning of a certain update. Perhaps it would be better to condense the informations somehow. Instead of telling the user the name of all 10.000 packages which are part of OpenOffice, just tell her, that an update of OpenOffice happens. Instead of giving a list of cryptic system packages, just tell, that a set of system core packages will be updated. Esp. the initial update after the system installation is very long and confusing...

Written by Rodrigo the 29 Jun 09 at 13:42.

Same as idea #1, which I personally believe is great. But then some more "advanced" user may like to know exactly what is happening in their systems.
So give them an option to see what packages (one by one) are being updated.

Same as idea #1, which I personally believe is great. But then some more "advanced" user may like to know exactly what is happening in their systems. So give them an option to see what packages (one by one) are being updated.

Written by jgoguen the 29 Jun 09 at 13:44.

Short version: Implement Solution 1, but allow the user to still see each individual package through an advanced view.

Long version: Condense update information into items more meaningful to average users, displaying only items such as "Firefox", "Evolution", "Core System", "OpenOffice.org", etc. but provide either a button or an option to display an "advanced view" that shows all packages.

Short version: Implement Solution 1, but allow the user to still see each individual package through an advanced view. Long version: Condense update information into items more meaningful to average users, displaying only items such as "Firefox", "Evolution", "Core System", "OpenOffice.org", etc. but provide either a button or an option to display an "advanced view" that shows all packages.

Written by Darwin Survivor the 29 Jun 09 at 18:57.

Why not make each "main package" (ex: OpenOffice) the top of an expandable tree?

Hit the + beside the package and see all the related packages that will be updated.


+Gnome
-OpenOffice
=OpenOffice.org
=OpenOffice.org_lan_en_us
+GIMP
+Mozilla-Thunderbird

Why not make each "main package" (ex: OpenOffice) the top of an expandable tree? Hit the + beside the package and see all the related packages that will be updated. +Gnome -OpenOffice =OpenOffice.org =OpenOffice.org_lan_en_us +GIMP +Mozilla-Thunderbird

Written by maccam94 the 20 Jul 09 at 23:30.

Initially display a window not much larger than a dialog box. Tell the user "It is recommended that you install # updates for your software." Have a "Show updates" button that expands the window and lists the individual updates. This choice would be remembered for future updates.

Initially display a window not much larger than a dialog box. Tell the user "It is recommended that you install # updates for your software." Have a "Show updates" button that expands the window and lists the individual updates. This choice would be remembered for future updates.

Written by dhaus111 the 28 May 09 at 20:28.

Have ubuntu check to see if there is a repo & key for the newly installed distribution and offer to convert from the old repo to the new one. It does this for universe and multiverse already, but with some server querying it can be done for custom repos also.

Have ubuntu check to see if there is a repo & key for the newly installed distribution and offer to convert from the old repo to the new one. It does this for universe and multiverse already, but with some server querying it can be done for custom repos also.

Written by mydoghasworms the 19 May 09 at 06:13.

A package manager should be able to verify the integrity of the package being downloaded by requesting a checksum for the package file from the central Ubuntu package server. That way users can know that the payload they are receiving is in fact genuine. This should be available as an optional feature in the package manager.

A package manager should be able to verify the integrity of the package being downloaded by requesting a checksum for the package file from the central Ubuntu package server. That way users can know that the payload they are receiving is in fact genuine. This should be available as an optional feature in the package manager.

Written by Gerwin the 20 May 09 at 07:19.

Let apt use something like https:// or ssh://

and let it automatically login on the server whit a user-name and password.

this way we will be able to now how many Linux users use the Ubuntu responsery.

And a reminder can be send to the email of a person if someone has not updated for a wile

It makes it more secure and new users wont forget to update.

Let apt use something like https:// or ssh:// and let it automatically login on the server whit a user-name and password. this way we will be able to now how many Linux users use the Ubuntu responsery. And a reminder can be send to the email of a person if someone has not updated for a wile It makes it more secure and new users wont forget to update.