Announcement of new packagebrowser?

[Erich Schubert]

Hello Enricho,

> Please consider Cc-ing the reply in deb-usability-list@lists.alioth.debian.org.

BTW: feel free to quote my debian-tags related messages into that list
as well. You don't need to include me in the recipients then, as i have
subscribed that list as well.

[ the newly added "junior" tag ]

> I'd rather keep subprojects-related tags inside the subproject
> themselves: since subprojects target a specific audience, their tagging
> needs to be subject to the rules of that audience, that are not always
> those of the generic Debian audience.
> 
> I really like the idea of subprojects doing custom tagging: it allows to
> use subjective tags when they make sense, while keeping the central core
> database pure, generic and as much objective as possible.

Most of their tagging is suiteable for all users (educational software
is educational, and games are games ;) and the additional "junior" tag
doesn't affect others. But they might contribute more to our project
this way. It might help promoting the subproject, which is a nice side
effect. When we disagree on some tagging with them we can still ask them
to move that tagging into a tag-diff file, that is easy.

> > Right now i use the following rule: packages not starting with a letter
> > but these few with a number aren't in subgroups.
> > When i tag a package and think the tagging is incomplete i remove the
> > not-yet-tagger-letter tag only, so the package appears on the upper
> > level "for review"
> 
> Yes, it makes sense.  It's handy, too.  Althought I'd suggest
> automatically replacing "not-yet-tagged" with "incompletely-tagged" in
> those cases, for clarity.
> 
> The operation should be simple: not-yet-tagged packages which have other
> tags, get "not-yet-tagged" replaced with "incompletely-tagged" or
> "needing-review".

the problem is that a lot of not-yet-tagged packages have been
automatically assigned tags by me, which might be quite wrong. I've had
packages that were tagged "gnome" but were actually non-gnome variants
or just "like gnome or kde". I'd prefer considering them as
"not-yet-tagged".

> I quite like "needing-review", now that I look at it: someone could add
> it to existing packages if they see them popping out in bad places.

You could also just move them back to "not-yet-tagged". The difference
between an untagged and a package with "broken" tags isn't too big.

> This could bring to the idea of "editors" tag (service tags for people
> editing the database), to be used for coordination and communication
> inside the cooperative editing structure, and if they bother they can
> easily be identified and stripped when exporting the database.
> 
> Some examples that come to mind:
> 
> 	Edit::not-yet-tagged
> 	Edit::need-review
> 	Edit::corner-case
> 	Edit::need-discussion

Hmm... i kind of dislike mixing this information with the other tags.
You don't want to have a "corner-case" subcategory. ;)
Still this makes it easier to search for such cases to discuss them.
But after all this collaborative editing is just a temporary solution.

> > the hierarchy is directly derived from the implication list. IMHO we
> > could need more "super-tags" to make this hierarchy easier to
> > understand.
> 
> Just pay attention not to force a tag to some package just to make the
> hierarchy come out easier: at the central database, I like the hierarchy
> to reflect the real distribution of qualities present in the collection.

I was talking about real super-tags like maybe "client-or-server" which
is a supertag of "client" and "server" (but not of "proxy" maybe, or
"net::vpn") - For example the "games" tag is such a super tag. When we
add a "games::other" tag every "games" package should have at least one
of the other "games::" tags as well.

> Subprojects and other distributors can then add new super-tags and
> implications to create hierarchies that are more understandable to their
> public (like the "specialized" tag that has been proposed by Colin
> Walters).  But the central DB will remain correct, at the point that it
> will probably suggest us new, unthought possibilities of hierarchy and
> other organization while the package pool will change and evolve.

The "specialized" tag should IMHO be added to the regular vocabulary.
Subprojects can introduce a new tag - kind of "highly-specialized" for
their use. I'd prefer this to them removing the "specialized" tag in
their patch files.

> This is the part that I like best of those automatic structure-making
> algorithm: since they have no prejudice, they can show you things that
> you've not yet been able to think about.

Yes, that is a really nice feature.

> > Yep, gui::gtk, gui::qt are also needed. But i'm not yet decided whether
> > we should use gui::gtk and have gui::gnome imply that, or wheter we
> > should name it gui::gtk-but-not-gnome (same for kde and qt)
> 
> It's hard to decide because they're two different metrics: gnome and kde
> are integrated desktop environments, while gtk and qt are windowing
> toolkits.  In that sense, gnome sure implies gtk, because gnome
> applications use that windowing toolkit, however applications using the
> Gtk toolkit can be part of Gnome, parts of some other desktop
> environment or also standalone applications.

I think there can even be applications that use a real Gnome UI but are
not integrated into the Gnome Desktop Environment.

> How about this:
>  Desktop::Gnome
>  Desktop::KDE
>  Desktop::XFCE
>  Desktop::GNUStep
>  [...]
>  Desktop::Standalone
> 
> And this:
>  Toolkit::QT
>  Toolkit::Gtk
>  Toolkit::Fltk
>  Toolkit::Lesstif
>  Toolkit::Athena
>  Toolkit::Xlib
>  Toolkit::AWT
>  Toolkit::Swing
>  [...]

I had been considering this before, but the problem is that Gnome isn't
just a desktop environment using GTK, but it does contain real
extensions to gtk. Nicer fileselectors, bonoboui and such.
OTOH I was thinking if we need to make the difference between gnome and
gtk actually visible in the package browser - most user won't care much.
OTTH there are packages like gconf that don't have an UI, but that
belong to Gnome (so they are real Desktop-Environment issues)
That is why desktop::gnome cannot imply ui::gtk. :-(

> Then mix as needed. It seems so much cleaner to me...  you could then
> have Desktop::Gnome correctly imply Toolkit::Gtk and Desktop::KDE
> correctly imply Toolkit::QT.

I'd prefer to stick with lowercase tag names and keep the "ui" hierarchy
instead of toolkit. You might have noticed that i had already named the
"ui" tag "User Interface and Desktop"
We could also need some "ui::graphical" (or ui::x11?) tag that allows to
remove text mode programs from the selection.

> > Below "authentification" we could use kerberos, maybe pam, sasl?
> 
> I've just checked dict: "authentification" should really be
> "authentication".  I liked authentification, though: it's so similar to
> its italian translation "autentificazione" :)

the german term is "Authentifizierung" that is where my spelling mistake
came from. Seems like the english lost a syllabe ;)

> Maybe you could try to separate data from structure, and have some of
> the structure rebuilt periodically by an external tool.  For example,
> the organization of tags in the package edit can be pre-computed and
> updated just every so often.

I have been considering this approach. Even caching the web pages a
couple of minutes does help much IMHO. But it doesn't matter right now.

>  On every change of tag in the database, touch a stamp file on disk
>  When you compute a hierachy page, write an on disk copy on it.  Then,
>  if asked for a page, if the on-disk copy is newer than the database
>  stamp file, output that one instead.

There are nice perl modules for such things. Cache::FileCache

Greetings,
Erich Schubert
-- 
   erich@(vitavonni.de|debian.org)    --    GPG Key ID: 4B3A135C    (o_
       The best things in life are free: Friendship and Love.       //\
      Ein Freund ist ein Geschenk, das man sich selbst macht.       V_/_