Re: Categorization of packages (was Re: Aptitude, ARs)

[Osamu Aoki <osamu@debian.org>]

Hi,

On Sun, Mar 16, 2003 at 03:20:21PM +0100, Enrico Zini wrote:
> them, and we should delegate the categorization to them, as we are
> doing now with sections.  If a devel chooses bad categories, people
> could file bugs; for the common case, however, we could expect that the
> majority of packages will easily get a good categorization with little
> effort.
...
> Before the wish list, I propose to do a step back and do some task
> analysis.

Also after this we need to prioritize them considering efforts needed to
achieve them.

> <brainstorm>
>  <call-for-contributions>
>   I definitely welcome other brainstormers to join in and create good,
>   comprehensive lists, which could serve as a basis to identify what we
>   are going to address.
>  </call-for-contributions>
> 
> 
>  * Intended users
> 
>  - Newbie Linux users, not in charge of administering the system
>  - Newbie Debian users, not in charge of administering the system
>  - Experienced non-technical Debian users, not in charge of
>    administering the system
>  - Experienced technical Debian users, not in charge of administering
>    the system
>  - Debian developers, not in charge of administering the system
>  - Newbie Linux users, in charge of administering the system
>  - Newbie Debian users, in charge of administering the system
>  - Experienced non-technical Debian users, in charge of administering
>    the system
>  - Experienced technical Debian users, in charge of administering the
>    system
>  - Debian developers, in charge of administering the system

I think these "User" thing can be summarized in 3 coordinates

User::Skill::Developer/Experienced/Intermediate/Newbie

User::Taste::Technical/non-technical
(Taste: There can be 2 types for "Technical" and this can be split.
"detail" oriented control freak for *production* server admin and "easy"
*personal* workstation admin.) 

User::Access::wheel/staff/user
(Access: wheel & staff may be merged as an administrator,)

4*2*3=24 possible combinations :-)

Also "User" may have different focuses 

User::Focus::Workstation::eduactional/medical/generic
User::Focus::Server::generic/web/mail/firewall

I think, in the end, in order to address all these different types of
user, we need more than menu presentation infrastructures.  Something
like policy-based configuration tweaking infrastructure especially to
address "Skill" things.

At this moment, I think this can be one "User".  Debian User :-)

Instead of addressing "User" factors,  we may be able to assign
"Relevance" attribute of each package for the typical uses.

>  * Purpose of the application

I guess you mean purpose of package management application.

It is:

1. to reduce task by the System administrator of any skill level and
   orientation, and
2. to provide information to the administrator and normal user for the
   availability and usefulness of the package.

   * Capabilities of the package management application.

> The package manager application is a complex one, in that it is used for
> many different purposes.
>  - Navigation among the available packages
>     - See what is available (what is in this Debian thing?)
>     - See what kind of problems or tasks have some package in Debian
>       that address them (what can I do with all these packages?)

I think "Topics" used by sourceforge is very good starting point for the
choice of "Topic".  Also "Task" used by Debian is another.

See http://people.debian.org/~osamu/pub/osamu-cat.txt for example of
these Topics.


>     - Examine the different alternative implementations for a given
>       feature (what choice of word processors do I have?)

This is basically way to present equivalent packages as an alternatives
under the menu entry for virtual package.

>  - Search the package database
>     - Find a specific package
>        - By package name (I want to see gnumeric package informations)
>        - By incomplete package data (what was that package I used last
> 	 year, it sounded like abi-something?)
>  - Manage the set of installed packages
>     - See what is currently installed in the system
>       (what has my system become?)
>       (disk is nearly full: do I have something I could remove?)
>     - Add/remove a single package (I wish to have libgnome2-dev for my
>       project)
>     - Add/remove a feature (I need a web server)
>     - Manage dependencies
>       (this package depends on these others: do I still want to install
>        it?)

      Not just 1 level but follow its tree.
      
>       (removing this package would involve removing these others: do I
>        still want to remove it?)
>       (this package wishes to have a web server: which of the different
>        alternative ones should I choose?)
>       (this package suggests this other one: do I want it?)

>     - System-wide actions
>        - Upgrade the system
>        - Upgrade to the next stable distribution
>        - Remove cruft packages

         - Show the impact of any of the above actions prior to do them.

> Other random ideas might be:
>  - show which packages are currently uninstallable
>  - show which of the installed packages have open
>    important/grave/critical or security bugs, or open bugs reported by
>    me
>  - show which of the installed packages have been orphaned

   - show which is maintained by DD or sponsored one

 - show low popcon rating of the packages installed
 - show high popcon rating of missing packages

 (Or we may need to reimpliment "better" popcon=popularity-contest.)

> </brainstorm>
> 
> 
> Once we have some analysis and we documented a set of tasks the
> application is to be used for, we will have a strong, common ground from
> which we can proceed:
> 
>  - evaluate how is the current situation: where it is good and where it
>    needs improvement
>  - elaborate proposed solutions and evaluate them
>  - build a roadmap for implementation, scattered with some user testing
>  - code, re-evaluating the current situation from time to time
> 
> 
> > 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.
> 
> At the LCA2003 BOF, in the limited time we had, we came out with these ideas
> for improving package metadata:
> 
>  - More than one section (tag/category) per package

Yes and no.

>  - Different instances of package descriptions: an application could
>    have a "general" description and a "technical" description for issues
>    of interest only to developers
>  - List of supported mime-types, to allow the user to do something like
>    "I want to view an application/postscript file: which packages are
>     available to do that?"
> 
> And then it was acknowledged that most of these metadata are not unique
> inside the debian universe, but could be different for each distribution
> flavour.  tuxpaint could have "toy" and "paint" category in one debian
> flavour, but only "paint" category in a Debian Juniour flavour.
> Also descriptions and priorities could change.
> 
> In fact, we considered the idea that creating a different debian flavour
> could mostly be limited to creating a set of different package data,
> priorities being the most important ones.
> 
> It was thus stated that flavour-specific data, like package sections,
> package priorities, default package selections and other user-related
> data, should not be inside packages themselves, but in external sources.
> 
> There are a dangerous lot of issues to address here.  I'm stuck between
> the fear of bringing too many issues in the discussion and get lost
> among them and the fear of holding issues to facilitate the discussion
> but then have to rework everything later on.

Exactly.

> I think, however, that the time has definitely come to start to
> seriously address this kind of user-centered technical problems.

In order to address these issues, I think most important parts is
creating infrastructures and guide lines to generate compact data to
address user needs.

After thinking more on this issue,I realized the issue in "volunteer"
project like Debian is to create and maintain good database to address
above concerns.  I think "popcon" like voting system which not only
collects installed package and their objective usage records but
collects more feedbacks from user how the user rate each program
installed and how relevant each programs are, may be needed to produce
these information. 

1.  People sign up from web and receive key with e-mail
2.  People run simple voting program and assign some key words and
    rating for each package which they installed on their system.
    (Sourceforge like Topics entry)
3.  E-mail it to server with key. (Some signing involve here)
4.  Tally them to create a list which can be used by menu system.

Osamu