Written by Menti the 28 Jan 10 at 21:41.

Besides other metadata such as the version number, support, etc, the date that the package was built could be shown.

Besides other metadata such as the version number, support, etc, the date that the package was built could be shown.

Written by Menti the 28 Jan 10 at 21:45.

Conceptually, the release of the code would be a lot more precise than the building of the package to indicate if the project is in active development. However, I don't know if that information is easily available and manageable to be dropped into USC.

Conceptually, the release of the code would be a lot more precise than the building of the package to indicate if the project is in active development. However, I don't know if that information is easily available and manageable to be dropped into USC.

Written by Menti the 28 Jan 10 at 21:54.

Whatever could be feasible and nice to have. For example:
-102 days since last version
-23 days since last security update

Whatever could be feasible and nice to have. For example: -102 days since last version -23 days since last security update

Written by Menti the 11 Feb 10 at 00:24.

What I would like USC to do for me is suggesting that a certain program could be no longer in development. So I wouldn't invest time creating data for that program that I might not be able to export to another program (for example, because the first one uses its own specialized data format).

Maybe a "sensible" limit could be set and warn the user when the package has not been updated for longer than that. Within that program's page in USC, a simple line could appear:

"This program has not been updated by its developers for more than two years."

I don't know if there are a lot of packages in Ubuntu that are old and get no updates, but are in use and there is no reason to avoid. Abundance of such packages would render this solution useless.

What I would like USC to do for me is suggesting that a certain program could be no longer in development. So I wouldn't invest time creating data for that program that I might not be able to export to another program (for example, because the first one uses its own specialized data format). Maybe a "sensible" limit could be set and warn the user when the package has not been updated for longer than that. Within that program's page in USC, a simple line could appear: "This program has not been updated by its developers for more than two years." I don't know if there are a lot of packages in Ubuntu that are old and get no updates, but are in use and there is no reason to avoid. Abundance of such packages would render this solution useless.

Written by Menti the 14 Feb 10 at 21:40.

The page of an application could have a button/link with a text like "Report this software as being no longer in active development". Pressing this button would send this information to Canonical.

This information could be treated and presented in very different ways. A warning could be shown, telling the user that the package is apparently dead. Or the number of "dead reports" could be shown. Canonical could treat the information with some kind of automatic system (such as "show warning when we receive 10 dead reports") or manually, and require human confirmation to tag a package as dead.

This solution is based on tntricker's comment. Merit is all his.

The page of an application could have a button/link with a text like "Report this software as being no longer in active development". Pressing this button would send this information to Canonical. This information could be treated and presented in very different ways. A warning could be shown, telling the user that the package is apparently dead. Or the number of "dead reports" could be shown. Canonical could treat the information with some kind of automatic system (such as "show warning when we receive 10 dead reports") or manually, and require human confirmation to tag a package as dead. This solution is based on tntricker's comment. Merit is all his.

Written by replicator-snail the 7 Oct 10 at 01:00.

For each package, calculate how actively maintained it is as a function of several factors (e.g. weighted by popularity-contest results, recent activity on Launchpad, frequency of releases, etc.), and display as an icon.

Example formula:
raw_score = K_1 * ln(# of current installs from popcon) + K_2 * ln(# of actions performed on launchpad in last year) - K_3 * ln(# of days since last update)
scaled_score = raw_score / (max(raw_score[i]) over all packages)

The icon could be something like a pie chart or LED. The color should be interpolated between green (most active) and gray (least active). Place the icon next to the package name (like the Ubuntu logo for Canonical-maintained packages in Synaptic).

For each package, calculate how actively maintained it is as a function of several factors (e.g. weighted by popularity-contest results, recent activity on Launchpad, frequency of releases, etc.), and display as an icon. Example formula: raw_score = K_1 * ln(# of current installs from popcon) + K_2 * ln(# of actions performed on launchpad in last year) - K_3 * ln(# of days since last update) scaled_score = raw_score / (max(raw_score[i]) over all packages) The icon could be something like a pie chart or LED. The color should be interpolated between green (most active) and gray (least active). Place the icon next to the package name (like the Ubuntu logo for Canonical-maintained packages in Synaptic).