After Debcamp/Debconf (what to do from now)

[Enrico Zini]

--WlEyl6ow+jlIgNUh
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello.

We're all back from LinuxTag/Debcamp/Debconf and I'd like to have a look
at the current state of things and see where we could go next.

I'm very happy that Debian Package Tags have been very positively
accepted by any person I've met.  This is a great encouragement and a
good indication we're on the right road.

I'm pleased to announce that I've worked a lot with Michael Vogt, the
author or synaptic, to implement package tags related functions into
synaptic.  The experimental synaptic-debtags package manager will be out
soon, and will be the first showcase for how package tags can be used to
dramatically improve a package manager: it will include browsing the
tag-derived hierarchy of packages and, most important, tag-based
filtering which allows to filter in/filter out packages based on their
tags: you could say, for example, show me all programs with mail, client
and ui::gnome.  You can imagine the exciting implications of this!

The debtags structure as it is now doesn't seem to need further
bugfixing, and it could be time to make it move forward.  Here's some
thing to do:

 - Add Descriptions and examples in the vocabulary

   If we want people to tag their packages, we need to make sure that
   they undestand their meaning.  The vocabulary is still quite lacking
   in this sense, and needs work.  For example, where we now have:

   Tag: 3d
   Description: 3D support (graphics, modelling, calculation, ...)

   we should instead have something like:

   Tag: 3d
   Description: 3D support
    This tag identifies applications and games who work with
    three-dimensional objects: graphics programs, modelling,
    calculation, fancy filesystem viewers, games and so on
   Examples: blender, povray, vegastrike, 3ddesktop

   This will involve cooperative editing of the CVS and discussion in
   the list: people interested in participating should send me a note
   with their alioth account name and I'll give them write access to the
   vocabulary CVS

 - Vocabulary translations

   The vocabulary needs to be translated, so that localized applications
   (synaptic, for example) can show translated tags.

   I should remind that the tag we use ("3d" in the example above) is
   just a unique identifying string to be used internally by
   tag-handling programs, but the tag name presented to the user should
   be, from the example above, "3D support".  In this way, to translate
   tag data we can just translate the whole vocabulary file and lookup
   the tag in the new one.

   We've talked with Javier Fernandez-Sanguino Pe=F1a at Debconf, asking
   what could we do to make easily translatable tag data, and he
   insisted that we provide .po files to the translator teams, so that
   they can use their existing tools to do the job.

   The idea is sensibile, and we should definitely do that.  I'm willing
   to write a program to do vocabulary<->.po transforms, as soon as we
   start to edit the vocabulary and we start having full entries so that
   tests and initial translations can be made.

 - Tags in debian/control

   Once we have tag descriptions in the vocabulary and synaptic-debtags
   starts being around, people will probably start using the package
   tags and we might want to proceed to the next big step, that is
   integration of tags in debian/control.
  =20
   When we get to that, we might want to set up some form of quality
   assurance system for tags.

   Most checks will of course come from people using the tag-enabled
   package managers, who will find packages out of place or won't find
   packages where they were expect it.

   Another possibility we've seen so far is to "adopt" a tag and check
   if the set of applications that use it is ok.  It's already possible
   to do now with this command:
     debtags cat | tagcoll reverse | grep ^<tag>:

   Another one is to have people expert in a given field responsible for
   checking the packages in that field: people who know gnome very well
   could take care of checking if the gnome applications are tagged
   consistantly.

   Other ideas for tag consistency checks are of course welcome


Besides package tags, even if I couldn't talk with many people about it,
it seems that my usability talk at debconf has been positively received,
and that there's a growing interest in this issue.  I've also noticed a
number of subscribes to the list during the debcamp/debconf days:
welcome everybody!


Another consideration is about the role of this list: so far it has
hosted general discussion and more specific technical things.  While
technical things can really use a separate list like this, I'm starting
to consider the idea of having general discussions held in debian-devel
and identified with the [usability] tag at the beginning of the subject
line.  I'd like to discuss this with other participants and eventually
reach some consensus.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

--WlEyl6ow+jlIgNUh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/IP969LSwzHl+v6sRAjdfAJ9gKCH/UXDqieoFXDzAZqCVN0Lp9wCgiPWX
5mOSV59s5EJ8d76wdnej2DU=
=f+8s
-----END PGP SIGNATURE-----

--WlEyl6ow+jlIgNUh--