[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 <enr...@debian.org>
signature.asc
Description: Digital signature