[Debtags-devel] Proposed Debtags goals for Etch

[Enrico Zini]

On Sat, Jul 16, 2005 at 11:15:41PM +0100, Justin B Rye wrote:
> Benjamin Mesing wrote:

> Time for a rush of new wishlist tags, then, right?  I have a stack
> of them I've been mulling over.

Push them on!

> >               * What about documentation packages? Would make 
> >                 implemented-in make sense for them too (e.g.
> >                 implemented-in::html, implemented-in::sgml,...)?    
> It's plausible enough to stretch "implemented-in::html" as far as
> docs packages, but not for, say, icons packages; personally I'd
> prefer to see a facet that worked as a general-purpose "made-of::".
> (At present format::html seems to be used largely for made-ofs, but
> also for packages like webbrowsers, which I suppose would be
> "works-with::html" if that existed). 

I like a lot this idea: it turns format::html into something meaningful.

I'll try to make a proposal for update:

  implemented-in and format are merged into made-of, resulting in
  something like this:

  made-of::lang-ada - Ada
  made-of::lang-bash - BASH
  made-of::lang-c - C
  made-of::lang-c++ - C++
  made-of::lang-fortran - Fortran
  made-of::lang-haskell - Haskell
  made-of::lang-java - Java
  made-of::lang-lisp - Lisp
  made-of::lang-lua - Lua
  made-of::lang-ml - ML
  made-of::lang-objc - Objective C
  made-of::lang-ocaml - Ocaml
  made-of::lang-perl - Perl
  made-of::lang-php - PHP
  made-of::lang-pike - Pike
  made-of::lang-python - Python
  made-of::lang-r - GNU R
  made-of::lang-ruby - Ruby
  made-of::lang-scheme - Scheme
  made-of::lang-tcl - TCL Tool Command Language
  made-of::format-html - HTML Hypertext Markup Language
  made-of::format-pdf - PDF Documents
  made-of::format-postscript - Postscript
  made-of::format-sgml - SGML, Standard Generalized Markup Language
  made-of::format-svg - SVG, Scalable Vector Graphics
  made-of::format-tex - TeX, LaTeX and DVI
  made-of::format-vrml - VRML Virtual Reality Markup Language
  made-of::format-xml - XML

Then there can be:

  format also merged into works-with, resulting in a further level of
  refinement:
  
  works-with::3d-model - 3D model
  works-with::3d-model-vrml - VRML Virtual Reality Markup Language
  works-with::archive - Archive
  works-with::archive-iso9660 - ISO 9660 CD Filesystem
  works-with::audio - Audio
  works-with::audio-mp3 - MP3 Audio
  works-with::audio-ogg - Ogg Vorbis Audio
  works-with::audio-vorbis - Ogg Vorbis Audio
  works-with::audio-wav - Wave uncompressed audio format
  works-with::bugs - Software bugs or other issues
  works-with::dictionary - Dictionary
  works-with::dtp - Desktop Publishing (DTP)
  works-with::fax - Fax
  works-with::file - Any file
  works-with::font - Fonts
  works-with::mail - Email
  works-with::music-notation - Music notation
  works-with::people - People
  works-with::pim - Personal data
  works-with::plaintext - Plain text
  works-with::plaintext-unicode - Unicode
  works-with::process - Running programs
  works-with::rasterimage - Raster image
  works-with::sourcecode - Source code
  works-with::spreadsheet - Spreadsheet
  works-with::textdocument - Complex text document
  works-with::textdocument-html - HTML Hypertext Markup Language
  works-with::textdocument-sgml - SGML, Standard Generalized Markup Language
  works-with::textdocument-tex - TeX, LaTeX and DVI
  works-with::textdocument-pdf - PDF Documents
  works-with::textdocument-postscript - Postscript
  works-with::vectorgraphics - Vector graphics
  works-with::vectorgraphics-svg - SVG, Scalable Vector Graphics
  works-with::video - Video and Animation
  works-with::video-ogg - Ogg Vorbis Audio

  I'm unsure where to place these, though:

  format::rss - RSS Rich Site Summary
  format::xml - XML

  and this indecision probably means that works-with is still a bit
  unclear.

These are a bit big changes: I'd like to hear some other voices before
going on doing them.


> >>  - if data goes automatically to the Packages file, we should have a
> >>    stricter control on what goes in. [...]
> > Why do we need stricter control for this? What is the difference in
> > automatically changing the package file and automatically changing the
> > debtags database (or is this not done automatically now?). Is one or the
> > other more likely to be "attacked"? 
> I don't know if it's happened to anybody else, but two or three
> times now I've seen debtags-edit suddenly decide it wants to add a
> huge collection of tags to its patch collection that I never asked
> for.  I've always managed either to catch them before submission or
> at least to follow up the garbled version with a manually-composed
> correction, but I'd hate to think there was a risk they'd go
> straight into the repositories.

This is strange to me.  Next time it happens, could you please post me
the patch so that I can have a look at what happens?


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: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050717/12138318/attachment.pgp