Le Lun 3 novembre 2008 16:36, Seth Vidal a écrit :
>
> If comps ends up with a thousand programs under Games and
> Entertainment,
> another thousand under Graphical Internet, etc., it's even more
> useless than
> having nothing in comps at all. What would be the point? On the
> other hand,
> having a thousand small comps groups is also no good.
>
So we're in the same boat if we start 'tagging' packages and/or if we
just
group them (which is essentially tagging from the other direction).
Let's take a step back. How do we group several thousand things such
that
they don't make the avg user lose his/her mind to look at them.
do we need groups of groups? A tree hierarchy the user can drill
through?
Font-sized tags like flickr/bloggers, etc?
I'm open to ideas, really. :)
Also:
- Hierarchical or tag-oriented classification ?
- Relationship between classification and spins/repositories/tasks?
- Single view of available repositories or multiple simplified
(task-oriented? spin-oriented?) views?
- Should we build those views from a single classification or can we
afford to maintain different classification efforts per spin?
- How are we going to merge classification from different repositories?
- What is the classification workflow for Fedora? For
third-party/private repositories without pkgdb access?
- Do we need the comps mandatory/default/optional tristate or
something else?
- How do we scale from a three-package private repository to a
Fedora-everything repository?
- Do we need to manipulate packages? Package groups? Something else?
- Do we need multilevel inheritance? (group A is in group B which is
in group C, etc)
- What is the right file format. XML, something else?
- How can a classification file/set of files be audited for syntax
errors (preferably in automated way)
- i18n needs?
- CLI tool needs?
- GUI tools needs?
There are lots of questions. Short term just putting everything into
comps is the way to go but for mid-term to happen it should start
soonish.
Regards,
--
Nicolas Mailhot