Making some tags mandatory

Fri Feb 27 11:48:30 UTC 2009

[if help is needed with following the proposal below: a list of tags and
 their description can be found at:
  * http://debtags.alioth.debian.org/tags/vocabulary.gz
  * /var/lib/debtags/vocabulary (if you have debtags installed)
  * http://packages.debian.org/about/debtags (formatted on the web)
 and can be searched with 'debtags tagsearch' or using the tag editor
 at http://debtags.alioth.debian.org/edit.html in the 'all' and
 'search' views]

Hello,

The way I see it, the last thread on sections has opened a bit of a can
of worms: now first everyone will want a section for their favourite
topic, then there is going to be a fight on which one to pick in case
packages that could belong to more than one section.  Been there, done
that :)

While I see a list of well defined sections that could still make a lot
of sense and carry a very practical meaning (namely, libs, libdevel,
deprecated (former oldlibs), debug, locale, kernel and data (for
foo-data packages)), other sections are clearly minor and belong
elsewhere (like the programming language for a library).

You said that debtags cannot yet replace sections because it is not
assured that all packages have tags: you have a point. Let's take care
of it.

I say that with the number of tags in the vocabulary approacing 600, we
just can't ask maintainer, ftp-masters, or anyone really, to know all of
them; but I can certainly come up with a 'core' list of tags that are
well defined enough, and that we can safely expect maintainers to know
about.

This is what I have to offer:

 * The proposal

At the end of this mail is the list that I propose: it's 138 of them,
but grouped as they are, they should be quite clear to grasp.  I
consider these groups of tags (debtags calls them facets) to be mature
and uncontroversial enough to be made official and to ask maintaners to
take care of them.

Besides proposing the tags, I offer to implement these three features
within a month from when we agree on a way for maintainers to add them
to the control file:

 - For packages with no tags in the control file, take the tags from the
   review tag set as we have now
 - For packages with tags in the control file, take tags in facets
   {role, implemented-in, devel, interface, uitoolkit, accessibility,
   admin} from the control file, and all the other facets from the
   reviewed tag set.
 - Provide a way for maintainers to show differences between the tags in
   their control file and the submissions on the debtags web interface,
   to be used as a sort of hint

I also offer to write lintian tests to ensure some consistency (role::*
must be there, implemented-in::* must be there if role::program is
there, and so on).

Note that this proposal can be implemented right now, as it introduces
new functionality without interfering with the existing one.

 * Future developments

In the future more groups of tags can become 'core', after a round of
discussion, polishing, and testing.  This discussion and polishing can
be done in the debtags side, without bothering/boring ftp-masters.

Tags first in the line to become core could be, for example, game::*,
hardware::*, mail::*, web::*, x11::*.

Some other groups of tags (biology::*, field::*, junior::*, made-of::*,
protocol::*, scope::*, suite::* and more) are probably better left to be
managed by groups of field experts.  The gnome/kde team is probably
better than any single maintainer in deciding what should have the
suite::gnome/kde tag.  Similarly, debian-med or debian-science people
can be called to have a say on tags of their interest.

Also, some tags like those in use::* or work-with::* are better assigned
the other way round, with people picking one tag and working to make
sure that the list of packages with that tag makes sense.

I am happy to come up with a workflow that allows such groups to have
the final say on their tags, and get the result integrated with the
rest: there are already several items in my todo-list that go in this
direction.  Maybe, even if game maintainers will easily be able to pick
a game::* tag, we will even decide that it will make more sense, for
consistency, that game::* tags will be managed by the Debian Games team.

But this is for the future.  For now, let's stick to the short term
proposal.

 * The list

Role of the package in the archive (mandatory for all packages):

  role::app-data - Application Data
  role::data - Standalone Data
  role::debug-symbols - Debugging symbols
  role::devel-lib - Development Library
  role::documentation - Documentation
  role::dummy - Dummy Package
  role::kernel - Kernel and Modules
  role::metapackage - Metapackage
  role::plugin - Plugin
  role::program - Program
  role::shared-lib - Shared Library
  role::source - Source Code

Language that the package is implemented in (mandatory for all packages
mostly consisting of software):

  implemented-in::ada - Ada
  implemented-in::c - C
  implemented-in::c++ - C++
  implemented-in::c-sharp - C#
  implemented-in::ecmascript - Ecmascript/Javascript
  implemented-in::fortran - Fortran
  implemented-in::haskell - Haskell
  implemented-in::java - Java
  implemented-in::lisp - Lisp
  implemented-in::lua - Lua
  implemented-in::ml - ML
  implemented-in::objc - Objective C
  implemented-in::ocaml - OCaml
  implemented-in::perl - Perl
  implemented-in::php - PHP
  implemented-in::pike - Pike
  implemented-in::python - Python
  implemented-in::r - GNU R
  implemented-in::ruby - Ruby
  implemented-in::scheme - Scheme
  implemented-in::shell - sh, bash, ksh, tcsh and other shells
  implemented-in::tcl - Tcl, Tool Command Language

User interface (mandatory for all packages mostly consisting of
software):

  interface::3d - Three-Dimensional
  interface::commandline - Command Line
  interface::daemon - Daemon
  interface::framebuffer - Framebuffer
  interface::shell - Command Shell
  interface::svga - Console SVGA
  interface::text-mode - Text-based Interactive
  interface::web - World Wide Web
  interface::x11 - X Window System

User interface toolkit (for packages with tags interface::{3d,
text-mode, x11}):

  uitoolkit::athena - Athena Widgets
  uitoolkit::fltk - FLTK
  uitoolkit::glut - GLUT
  uitoolkit::gnustep - GNUstep
  uitoolkit::gtk - GTK
  uitoolkit::motif - Lesstif/Motif
  uitoolkit::ncurses - Ncurses TUI
  uitoolkit::qt - Qt
  uitoolkit::sdl - SDL
  uitoolkit::tk - Tk
  uitoolkit::wxwidgets - wxWidgets
  uitoolkit::xlib - X library

Role in the context of software development (as needed):

  devel::bugtracker - Bug Tracking
  devel::buildtools - Build Tool
  devel::code-generator - Code Generation
  devel::compiler - Compiler
  devel::debian - Debian
  devel::debugger - Debugging
  devel::doc - Documentation
  devel::docsystem - Literate Programming
  devel::ecma-cli - ECMA CLI
  devel::editor - Source Editor
  devel::examples - Examples
  devel::i18n - Internationalization
  devel::ide - IDE
  devel::interpreter - Interpreter
  devel::lang:ada - Ada Development
  devel::lang:c - C Development
  devel::lang:c++ - C++ Development
  devel::lang:c-sharp - C# Development
  devel::lang:ecmascript - Ecmascript/JavaScript Development
  devel::lang:fortran - Fortran Development
  devel::lang:haskell - Haskell Development
  devel::lang:java - Java Development
  devel::lang:lisp - Lisp Development
  devel::lang:lua - Lua Development
  devel::lang:ml - ML Development
  devel::lang:objc - Objective-C Development
  devel::lang:ocaml - OCaml Development
  devel::lang:octave - GNU Octave Development
  devel::lang:pascal - Pascal Development
  devel::lang:perl - Perl Development
  devel::lang:php - PHP Development
  devel::lang:pike - Pike Development
  devel::lang:posix-shell - POSIX shell
  devel::lang:prolog - Prolog Development
  devel::lang:python - Python Development
  devel::lang:r - GNU R Development
  devel::lang:ruby - Ruby Development
  devel::lang:scheme - Scheme Development
  devel::lang:sql - SQL
  devel::lang:tcl - Tcl Development
  devel::library - Libraries
  devel::machinecode - Machine Code
  devel::modelling - Modelling
  devel::packaging - Packaging
  devel::prettyprint - Prettyprint
  devel::profiler - Profiling
  devel::rcs - Revision Control
  devel::rpc - RPC
  devel::runtime - Runtime Support
  devel::testing-qa - Testing and QA
  devel::ui-builder - User Interface
  devel::web - Web

Accessibility support:

  accessibility::input - Input Systems
  accessibility::ocr - Text Recognition (OCR)
  accessibility::screen-magnify - Screen Magnification
  accessibility::screen-reader - Screen Reading
  accessibility::speech - Speech Synthesis
  accessibility::speech-recognition - Speech Recognition

Role in the context of system administration:

  admin::accounting - Accounting
  admin::automation - Automation and Scheduling
  admin::backup - Backup and Restoration
  admin::benchmarking - Benchmarking
  admin::boot - System Boot
  admin::cluster - Clustering
  admin::configuring - Configuration Tool
  admin::file-distribution - File Distribution
  admin::filesystem - Filesystem Tool
  admin::forensics - Forensics and Recovery
  admin::hardware - Hardware Support
  admin::install - System Installation
  admin::issuetracker - Issue Tracker
  admin::kernel - Kernel or Modules
  admin::logging - Logging
  admin::login - Login
  admin::monitoring - Monitoring
  admin::package-management - Package Management
  admin::power-management - Power Management
  admin::recovery - Data Recovery
  admin::user-management - User Management
  admin::virtualization - Virtualization

Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20090227/8324e396/attachment.pgp 