Miscellaneous notes
-------------------

Some analysis techniques:

Consistency checks on facets that should go together::

  # Show all packages which have a tag in uitoolkit but not a tag in interface
  # (same can be repeated for hardware and hwtech, devel and langdevel)
  debtags facetcoll | grep uitoolkit | grep -v interface | cut -d: -f1 | sort | uniq

  # Count the number of facets
  debtags facetcoll | tagcoll reverse | wc -l

  # Get a list of toplevel facets in a facet hierarchy
  debtags facetcoll | tagcoll hierarchy | cut -f2 -d/ | cut -f1 -d: | sort | uniq


Interesting links:

 * http://www.itconsult.it/knowledge/articoli/detArticoli.asp?ID=18


TODO-list items being worked on
-------------------------------

These are the TODO-list items currently being worked on::

noshadow> enrico: is there some way as maintainer to regulary (i.e. low efford
          once properly configured) look at one's packages' tags (and best to
          also edit them) without needing root, something newer than etch or
          something doing javascript?
enrico> djpig: indeed (wrt the 15000 packages bof ideas)
enrico> noshadow: comment the apt line in /etc/debtags/sources.list and uncomment
        the alioth line
enrico> noshadow: then debtags update will get the unstable tags
enrico> noshadow: then debtags-edit, or debtags tag add, debtags tag rm, debtags
        tag list...
enrico> noshadow: and debtags submit
enrico> noshadow: without needing root it's partly possible but a bit tricky
enrico> noshadow: it's never been requested before and it'd be quite a bit of
        work to make it work properly
enrico> noshadow: not too much work: getting sources from ~/.debtags is already
        implemented; only, they are merged with the system ones
enrico> noshadow:  one'd need to implement a ~/.debtags/sources.list that
        overrides the system one

 - Smart querying:
    1. full text search
    2. get the n (=3?) most recurrent tags (possibly multiplying their
       cardinality in the result by the tag score, to add a user-defined
       weighting)
    3. Add all the items whose tagset contains the n most recurrent tags
    4. Allow to AND or AND NOT for tags, possibly allowing the user to choose
       among the most recurrent tags
   Resulting query:
    ((Full text UNION "similar" items) UNION and items) INTERSECTION and not items

 - Allow to have ~/.debtags/vocabulary merged in
 
 - Try to get rid of the Singleton Environment

 - Remove throw declarations altogether except when the function obviously
	isn't throwing and won't be throwing anything.

 - perl bindings crash at shutdown: it looks like #186104: check what it was,
	and check how it has been corrected
	 - Does not seem to be the case:
	   TDBReadonlyDiskIndex's destructor reports garbage in the size of
		newItems, even if nothing has been ending up on it (that is,
		~/.debtags/patch has been moved aside).

 - Remove all PackageDB-related functions: libapt-front should be used for
	that.  PackageDB itself probably needs to stay for the APTFilter in Update.

 - Impossible now to detect out-of-space errors because TagcollSerializer isn't
	checking the return code of fprintf (changing it would break libtagcoll
	binary compatibility)
	(fixed in libtagcoll, should handle it appropriately in libdebtags)

 - Sending mail to central database aborts if the mailserver fails

 - See if mor standard c++ features can be used

   use of functors (``operator()``)

   The Debtags::Matcher is a good candidate for this one, having the same
   implementation like the match function. With this the code in
   TagSet::getFiltered could be implemented using a the copy_if() algorithm.
   Uhh... the above is hard to read. I mean the operator() could be added to
   the Debtags::Matcher() - where it could be used in std algorithms.
 - todoreport should mention that the number of packages has been limited

 - specials: given a facet A, for all other facets Bn generate a list of
   packages that have A and not Bn

 - generate one todoreport per maintainer

 - debtags related does not work
   ("debtags -d 14 related debtags" doesn't output anything

 - Statistics and automated checks:
    - Experiment with theory:
       - there should never be two packages with the same tagset: if it happens, a
         new facet may need to be created
       - Make a debtags function to detect when it happens

 - In grep expressions, allow to use and, or or not (hiddenly replacing them
   with &&, ||, !), now that tags always have :: in them

 - Code
    - In debtags update, print the names of packages that are not in the debtags
      archive
    - On debtags update, filter out tag data for packages not existing in the
      system
    - On debtags update, output a list of the packages not present in the tag collection
    - Usare "foreign" nell'inizializzazione di automake, in modo che non richieda il changelog
      (e cancellare il changelog) (anche negli altri pacchetti)
    - Make a CommandlineParserWithCommands supporting command-specific switches:
      addCmdSwitch("command", <same args as add()>)
      addCmdSwitch("", ..) adds a switch that gets interpreted when no valid
        command is found
      The option parsing should then scan until it finds the first non-option
        argument and see if it's a command, then re-scan the commandline with the
        good set of switches in effect.  There's a problem in this with arguments
        to short switches, like '-o file': `file' could be interpreted as a
        command and not as an option to `-o'.  Could be solved by having all
        switches be considered when scanning for the command, or (better) by
        scanning once for each command until a valid match is found

 - debtags install: Allow to call aptitude instead of apt-get

 - [erich] I had the idea that people can "adopt" a keyword, looking for
   volunteers to review a section regularly.


Future TODO-list items
----------------------

These are the TODO-list items that are to be addressed in the future::

 - Try wrapping with http://www.boost.org/libs/python/doc/index.html

 - Make a small LRU cache of Facets and Tags in Vocabulary, so that some
	TagImpl and FacetImpl are reused

 - Update doesn't really merge different tag sources
   (need more info) (seems to work for me: where does this come from?)

 - Implement failover strategies in case the vocabulary (or other files) are
	not present

 - Create new tags / facets
 - Save a vocabulary patch

 - Make a more efficient collection container than InputMerger for the
	operations performed by libdebtags

 - port foundation libraries to libboost when possible
 - Merging different tag sources
    - Scenario: I want to edit tags when I have multiple tag sources, submitting
      appropriate, separate tag patches to the tag sources which are in charge of
      the tags that changed.
       - Including a local, user defined, tag hierarchy (preference::interesting,
         preference::useless, preference::tried...)
    - Add origin to facets and save a different patch for every origin
    - [me]
      It could be interesting to outsource the first tag layout of such parts
      to the relative communities: for example, we could ask the gnome people
      to provide the right tag vocabulary for gnome-related qualities.
      I guess they may be happy to do it (and to be kept in consideration by
      the Debian people), and surely they know what are right qualities in
      their world.
 - Add Extends: apt to control file (like guessnet does with ifupdown)
 - Allow to manipulate a local vocabulary (~/.debtags/vocabulary ?)

 - Integrate with APT
    - See if it's possible to hook debtags update after apt-get update
    - Patch apt-cache to exec debtags for some things (when debtags is installed)
      [zufus]

 - When adding new tags to the vocabulary, announce them to debian-devel
   (no faster than weekly)
 - Maintain an upgrade checklist for the vocabulary.  cvs diff can help
   generating it

 - Since we're somehow similar to semantic web, have a look at what it is, how
   it works and how crossing that path can be useful

 - Navigazione: l'utente induce nella tagged collection una struttura a lui
   specifica, avvicinando categorie e allontanandone altre.  Questo può anche
   essere mappato bi o tridimensionalmente, con animazione.

 - Erich:
   This to improve in synaptic-debtags:
    - make the tree less deep, don't make subfolders if only < 10 packages are
      left etc.
    - show tag descriptions.
    - handle "virtual" tags in the tree, such as "ui", which basically is a
      union of "ui::gtk", "ui::qt", "ui::ncurses" etc. (virtual tags: tags
      where all packages are in a subgroup)

   Things to improve with debtags in general:
    - more tagging. Too many packages are still untagged
    - inconsistent tagging. New tags were added, so many tagged packages are
      incompletely tagged. For example many applications don't have a user
      interface specified.
    - inconsistent tags. some features have tags, others don't.
    - structure is becoming to deep IMHO. but if you want to keep the
      number-of-results low you need such a deep structure.

 - [Javier Fernández-Sanguino Peña]
   Have a look at TFIDF systems (implemented in bow) to use them to find out tags.
   The suggestion comes from Javier Fernández-Sanguino Peña <jfs@computer.org>,
   who's happy to help with problems understanding TFIDF
 - Ask for someone in the i18n team to join in, to help with the design of the
   language dependent files with tag names and descriptions.



Discarded TODO-list items
-------------------------

These TODO-list items have been discarded::

 = Note to the vocabulary task force: "mail,net" is a single tag, "mail, net"
   are two tags
   (this is an old note that doesn't make much sense anymore)
 = Note to the vocabulary task force: rub "debtags check" from time to time 
   (this is an old note that doesn't make much sense anymore)
 = [chlunde] Don't crash when giving data about a non-existing package: it
   might happen, such as when using the full database on a system without
   non-free.  Don't show the application, instead.
   [chlunde is working on it]
   (old note, fixed since long time on debtags-edit)
 = Consider implementing version information in Package, allowing more
	Package-s with the same name but with different versions in PackageGroups
	(can do by changing Package's comparison operators)
	 - Consider then doing dependency computations, like
	   PackageGroup PackageGroup::getDepends();
	   PackageGroup PackageGroup::getRecommends();
	   PackageGroup PackageGroup::getSuggests();
	   PackageGroup PackageGroup::getConflicts();
		...
 = Allow more flexibility in Package representations
	 - Make PackageImpl somehow more public, so that people can subclass it and
		write Package-like classes with more informations (as you can't subclass
		Package, being it a smart pointer)
	 - Make PackageSet a template, to which you can pass Package or something else
	 - Rename Package into BasicPackage
	 - Make a Package virtual interface

 = Bring in dependency info from synaptic (rpackage.h)
   Subversion: https://oops.kerneljanitors.org/repos/synaptic/trunk
	PackageSet Package::getDepends()
	PackageSet Package::getSuggests()
	PackageSet Package::getRecommends()
	PackageSet PackageSet::getDepends()
	PackageSet PackageSet::getSuggests()
	PackageSet PackageSet::getRecommends()
	(no: leave that to libapt-front)
 = Environment: accept the filter as const
 = Implement filters, searches and consumers also for MaintainerSet
 = Find out how to efficiently search a std::set<Package> given the package
	name, though: #include<algorithm> could come useful, hopefully, as it would
	come useful to see what operators are supported by the set iterator (it
	would be wonderful if it had tree operations...)
 = See how it is possible to be a base for libcapture
 = Integrate Maintainer info with Echelon data (from Debian LDAP database)
 = Do popcon researches as well

(older discarded items are archived in the DONE file)