Re: Categorization of packages (was Re: Aptitude, ARs)
On Sun, Mar 16, 2003 at 12:55:12AM +0100, Enrico Zini wrote:
> On Sat, Mar 15, 2003 at 11:26:40AM -0800, Osamu Aoki wrote:
> 12585+ packages are an interesting problem which poses non trivial
> usability problems and calls for some research on information
> visualization techniques.
Spend 20 seconds to assign several keywords to a package
12585 binary packages translates
12585 * (20/60) * (1/60) hours = solid 69 hours :-)
It is non trivial. (I guess Daniel spent at least 20 solid hour
even with 10 sec/package speed to finish for woody)
Just to finish current one within current structure, I see over 20 more
hours to do it. Long hours... (If we go by source package there are
about 7000 packages in unstable) *non trivial* for sure.
Anyway, Enrico, you seem to have lots of interesting ideas and programs
in terms of algorithm. Before launching implementation, maybe we should
set "expectation" and "success criteria" for menu system from user's
perspective.
Let's list wish list:
0. As much entry shall be hidden and set by default to reduce clutter.
1. I do not want to see all the library packages, task contents, -dev
packages, -doc(s) packages, selection of virtualized packages or
selection of l10n packages until I choose to change defaults.
2. The package selection process should provide default automatically
through the policy on the system. Things like choice of newest, 2nd
newest or maturest version library shall be policy issue. So as
whether corresponding -doc or -dev are installed or not.
3. Recommend/suggests should have policy based defaults.
4. There shall always exist a way to override policy for finer grain
admin control.
5. If package offer alternative, they should be grouped and only
display one entry with the highest score alternative one, such as vim,
shall be chosen as the default over lower score nvi. choice of
xemacs21 or xemacs20 shall be governed by a policy similar to the
policy for library (some people like latest, some wants rock
solid.).
6. Use some hushed database for the sake of speed :-)
7. If the number of automatically chosen packages reach user set limit,
user shall be given option to check dependency tree while presented
with the fact "how many packages are selected by the auto-selection".
User should be able to override auto-selection. (If threshold is set
to 0, it is same behavior as dselect)
8. If selection per screen is more than 50, we need finer category or
we need some priority score system to reduce its display.
9. ... please add here :-)
Once we exhaust these wishlist and prioritize them, we write down how to
assign some key words/properties to each package. Split the task, then
consolidate data to create final data.
Any suggestions for roadmap and expectation.
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +++++
Osamu Aoki <osamu@debian.org> Cupertino CA USA, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
Reply to: