Older closed TODO-list items
============================

These are the TODO-list items that have been closed in older releases::

 *** Done in the old tagcoll package


 *** Done in tagcoll 1.0
 
 --- 2005-04-10
  + Ported to libtagcoll 1.0
  = Make TagCollection a template wrt the item format
    (I *badly* need to discover how to distribute templates inside libraries!)
    (obsolete: done since long ago)
 
 
 *** Done in tagcoll 0.99
 
 --- 2004-07-25
  + Ported to libtagcoll 0.99
 
 *** Done in tagcoll 0.16
 
 --- 2003-07-18
  + Another optimization would be to remove intermediate hierarchy nodes wich
    contain a single child node and no elements.
 
    It could just be implemented by merging tagsets with cardinality under a
    given threshold into the nearest, bigger one.  Like filtering insignificant
    or "noise" tag data before building the structure.
 
    The optimization must be kept optional, because it induces a loss of tag
    informations if the resulting tagged collection is used as the only way to
    store the results like with tagbk
 
  + tagcoll: merge equivalent tags
    If a tree node has only one child non-leaf node, compress them in a single
    one merging the tree tags.  For example: /a/b/ could become /a,b/
 
 *** Done in tagcoll 0.15
 
  + Port to libtagcoll 0.4
  
 *** Done in tagcoll 0.14
 
  + Package the common tagcoll functions in a separate library
 
 *** Older versions
 
  + Separate the source parser from the rest; make the sorting algorithm sort
    integer handles to real items, giving in input the integer handles and
    their cathegory set and in output the hierarchy.  The upper level will then
    keep track of the handle -> real item association, input parsing and
    generation of output
    Problem: in which internal format should the result tree be generated?
    Solution:
    class Node
    {
    	vector<Node> subnodes;
    	set<int> leaves;
    };
    Problem: in which internal format should the input items be presented?
    class Input
    {
    	map< string, set<int> > tags;
    	set<int> orphans;
    }
  + Write a hierarchy sorter using /usr/share/aptitude/function_pkgs and
    function_groups as data
  + Instead of working with all the single items, work with groups: make a group
    with all the items that have identical tag sets, and just remember the
    number of items present in each group.  Then build the hierarchy, and
    populate it with the items in a second pass.
     = This does not work: tagsets are merged and reworked during the sort, and
       there is no way to find out what packages belong to each hierarchy node
  + tagsorter: make an option to list the implicit implications found in the
    input data, instead of the hierarchy
  + the implicit implications can be in the form tag:<tags that imply it>, and a
    hierarchy can be built out of that
  + add a --explicit-implications switch to read an explicit implication list
  + add a --copy switch to output the tagged collection unchanged: to be used
    with --explicit-implications to produce an expanded collection
  + add a --pack switch (requiring --explicit-implications) to contract a
    tagged collection removing all tags covered by the explicit implication file
    from it
    Example: given implication `gnome: gui, desktop', then it would remove the
             tags `gui' and `desktop' from all tagsets containing `gnome'.
  + add a --rename-tags-from to read a mapping list stating that a given set of
    tags should be renamed with another tag on input.
    Example:
    mp3: MP3, Mp3
  + add methods can compute bad tag cardinalities if an item is added that is
    already part of the collection
  + write a tagged collection diff and patch utility, able to detect tagged
    collection changes, where a change simply is the add or removal of a tag to
    an item.  In this way, multiple concurrent changes to a collection can be
    merged.
  + Change the parser to use /:\s+/ instead of /:\s*/ to separate items from
    tags.  In this way there is the possibility of using ':' in tag names to
    simulate namespaces ("lang:ml", "mail:ml"), and such tag names won't
    corrupt the output of --show-implications, nor need some extra escaping all
    the time.
  + Rearrange switches.  Produce packed output by default, and use a --expanded
    switch to request for fully redundant output
  + Roadmap
     + Prepare a tag vocabulary and keep it in CVS.
       Repository name: pt-normative
       The vocabulary should contain:
        - A list of all possible tags
        - A brief semantic description of the tags
 	- Optional explicit implication list for the tags
 	- Optional notes for complicate tags
     + Test tagcoll a little more and upload it in sid, so that it will be ready
       when we need it.
       (Herv, you're the best tester that I've ever had: be as mean as you
        can get! :)
     + Prepare the `package-tags' package
        + Decide a method to download the last version of the tag database
	+ Ask erich if he can setup some output method with a single unique URL
        + Decide if the tag vocabulary should be routinely downloaded as
          well or it it's enough to ship a copy of it inside `package-tags'
        + Include some example toy so that people can start playing with
          tags (like my script to generate the static HTML browser, a text
          file showing example tagcoll manipulations of the data and other
          toys we might like to write for the occasion)
     + Make an announcement in debian-devel about what we've done and where
       `package-tags' can be downloaded (experimental, maybe?) to be tested.
     + Eventually start using a public mailing list (-devel?) for
       discussions instead of private mail
  + Write a script that extracts the explicit implication list from the
    vocabulary
     + debtags implications
  + Write a script to check a tagged collection against the vocabulary
     + debtags check <filename>
  + debtags: non si pu coabitare con apt, che si lamenta se vede 'tags' nel
    sources.list.  Usare /etc/debtags/sources.list.
  + Feature from Erich:
    > This is another nice frontend. "Show me packages similar to this one" is
    > a /really/ nice function.
    > BTW: i think we should expand this system beyond packages to
    > applications. "apropos" sucks nowadays, it usually lists hundrets of
    > matches. But a tags-based apropos would be /really/ cool.
    > especially with that similarity function. "biff" is almost what i want,
    > what is similar (but with x11 tag)? oh, xbiff. fine.
 
    Definire "distanza" tra due oggetti in una t.c. come la cardinalit
    dell'insieme differenza tra l'unione dei tagset dei due oggetti e
    l'intersezione dei tagset.  La similitudine tra due oggetti diventa quindi
    un valore inversamente proporzionale alla distanza.
  + Also try a "similar to item1, item2, .., itemN", as the ones with the least
    distance from the intersection of the tagsets of all these
  + debtags: let "show" and "cache" do the same of apt-cache, and proxy them to
    the real apt-cache
  + debtags: use tagshow and tagsearch to work on tags
  + debtags: port to getopt::long
  + debtags: write a manpage
  + debtags: add a "related" search
  + debtags: apply patches in sorted order from files in /etc/debtags/patches.d
    at update time
  + Write a README.Debian for debtags
     - Write a quickstart session
     - Give some rationale about package tags
     - Why that way
 	 - What can you do with them
 	 - Advantages
	    - Structure build and updates automatically from the existing
	      package qualities
 	    - Description of packages from different points of view
 	    - No need to define and order of importance between qualities
 	      (compared to hierarchical organization)
 	    - Explain how it's been implemented in Debian so far
 	    - Erich's Package Browser / cooperative editor
 	       - Normative vocabulary
 	       - Task force
               - CVS editing
 	       - Central package tags database
  + tagcoll: subclass CommandlineParser to CommandlineParserWithCommand,
    managing the first argument as a command
     + Make an addCommand(string name, int val) method
  + tagcoll: --implications-from is not working
  + Update the mkbrowser script to use debtags and add it to debtags exaples
  + debtags: when proxying the `show' command, subtly add tag informations to
    its output
  + Revision the tags
  + Update the vocabulary with the last data from the DB
  + The hierarchy can also be created on-demand for interactive applications:
    just leave in the child nodes their child tagged collection, and expand it
    only when needed.
  + tagcoll: since the tagging generation can be incremental, implement it, and
    output smart hierarchy lines as soon as they are computed
  + incremental generation can also be used to compress subtrees: when the size
    of a child collection is small, directly get the list of children
  + A further optimization would be to flatten subhierarches that contain less
    that a certain threshold number of elements.
  + Make the announcement
  + Tagcoll: add the possibility to "reverse" a collection, that is to output it
    as:
    tag: item1, item2, item3...
    [ender]
  + define "derived tags", that is, tags that are a derived from others.
    Like: userlevel::novice = !specialized && (interface::gui || interface::curses)
    The functions can be present in the vocabulary and computed by debtags
    update during the creation of the package database
    [David Roundy]
  + debtags: do not add Tags: informations to empty apt-cache outputs
  + Include a version of the tag database in debtags.
    [Colin Walters]
  + Add a (commented) source pointing to the tag database shipped with debtags
  + Add the possibility of having a local vocabulary that is merged to the one
    provided by debtags.  It could be used to add local implications or local
    derived tags
     - For example, "specialized" could be implied by some tags, but only in a
       custom vocabulary provided by some subdistro
    [Colin Walters]
  + debtags update should then update the vocabolary, too
    [Colin Walters]
  + debtags update should extract implications and derived tags from the
    vocabulary and store them in separate files inside /var/lib/debtags
  + debtags: do the patching with the implications from the vocabulary at import
    time.  They can be removed at any time with the compress function, but in
    the meantime the system tag database will be complete.
  + [erich]
    tagcoll: ad an option to compress a tagcoll file as
    item1, item2, item3: tag1, tag2, tag3
    But keep it an optional feature, to use just for things like distribution of
    database, since having that format for the database as a default would
    impact of the ability to process it with normal unix tools
    (like doing grep ^item: on it)
     - The parser could be made agnostic on the format
     - The serializer could instead be chosen in the compact form by a
       commandline switch
    This should be in the version that goes in sid, so that Erich can change the
    format at any time
  + [io]
    Use the expression parser to add an option to grep the database printint
    only the items that match (or do not match) a given pattern
    tagcoll [-v] grep "expression" file
    or
    taggrep [-vq...] "expression" file ...
  + debtags:
     + store the tag collection in the most compact form
     + add a "cat" command that outputs the tag collection fully expanded
     + add a "grep" command that calls taggrep on the expanded collection
  + debtags: add a method to display all the packages with a given tag or set of
    tags
    [ender, Kevin B. McCarty]
 



 *** Done in the old libtagcoll1 package

 * Version 1.0.1
 
 + Added InputMerger::itemCount()
 + Added InputMerger::clear()
 + Remove redundant items from the patch on TDBReadonlyDiskIndex::setChanges
   and applyChanges

 * Version 1.0

 + Generate -pic library together with the normal -dev
   http://lists.debian.org/debian-devel/2005/05/msg00425.html
   discover1-1.7.7 is an example of program generating -pic libraries with automake
	from discover1's debian/rules:
	  # This builds the pic library
	  ar cqv lib/libdiscover_pic.a lib/.libs/*.o
 + Renamed package to libtagcoll1
 + Removed default template arguments: now everything needs to be explicit
    ! API change

 * Version 0.100

 + Added unit-test suite invocable with make check
 + Added FastIndex, Serializer, TDBFastIndex
 + TDBFastIndex tests succeed
 + Only build the static library
 + Only package the -dev version
 + 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)
	Done: now that we only package the -dev version, I can freely change the ABI
 + Renamed TagToString.h in SerializationFilters.h and generalised it using
   Serializer
	 ! API change
 + Make ExpressionFilter a template for the item part
 + Added TaggedCollection interface
 + InputMerger implements TaggedCollection
    ! API change: The previous getTagsetForItem becomes getTags
 + Make FastIndex implement TaggedCollection
 + Generalised the Patch system
    ! API change
 + Unify TagcollChange and the patch system
    ! API change: TagcollChange replaced with PatchList
 + Make TagCollection implement TaggedCollection
 + Make a TDBReadonlyFastIndex, that keeps the changes in an internal patch
 + Rename FastIndex in DiskIndex
 + TagcollSerializer should take a Serializer parameter
    ! API change: TagcollSerializer renamed in TextFormat
    ! API change: TextFormat now wants a Serializer
 + Merge TagcollParser into TextFormat
    ! API change: TagcollParser is now TextFormat
	 ! API change: TagcollParser::parseTagcoll is now TextFormat::parse
	 ! API change: the parser which applied instantiations and whatnot has been removed
 + Serialize and parse the new patch
    ! API change: patches cannot be serialized using a normal TagcollConsumer anymore
 + Add getItems and getUntaggedItems to TaggedCollection
 + Make a testTaggedCollection test function that tests a generic
	TaggedCollection (with strings and with tags)
 + Move existing Tag-related classes to libdebtags
    ! API change: everyone is in charge of providing their own Tag implementation now
 + Make a TDBFile class with the functions to access a TDB file

 
 * Version 0.99.1

--- 2004-08-15
 + Tagexpr: match the wildcard asterisk '*' at the beginning or end of the tag
   name (can now do taggrep *::server && mail::*)


 * Version 0.99

--- 2004-08-01
 + Tag and Facet: allow to memorize the full range of data available

--- 2004-07-27
 + Added UnfacetedRemover from libdebtags
 
--- 2004-07-26
 + README updated!
 + Tag::operator< has lexicographical compare implemented wrong
 + FacetImpl::obtainTag is an unmodified copy of FacetImpl::getTag

--- 2004-07-24
 + [.cc files] Require includes to be included with an explicit path, as in
   #include<tagcoll/header.h>
 + Generate libtagcoll1 instead of libtagcoll0
 + Introduce doxygen in the build system
 + Fix version number in library soname

--- 2004-07-23
 + Move names in the Tagcoll namespace
 + Added the Tag, TagSet, TagConsumer, BasicTagMatcher classes from libdebtags
 + Expand templates: don't depend on the tag being a string
 + Removed template instantiations with int items, as they can now be
   instantiated by applications when they need them
 + [headers] Require includes to be included with an explicit path, as in
   #include<tagcoll/header.h>


 * Version 0.9

--- 2004-07-07
 + InputMerger template: don't depend on the tag being a string


 * Version 0.8

 + Applying to InputMerger a TagcollChange containing a non-existing item makes
	the function segfault


 * Version 0.7

--- 2004-06-29
 + Put .cc files with templates in include
 + Remove Package* instantiations
 + Move instantiations on a instantiations.cc file, to avoid being included by
	other instantiators
 + Ported to cdbs
 + InputMerger::output is now const

--- 2004-06-28
 + InputMerger: Also compute related items starting from a tagset


 * Version 0.6

--- 2004-05-20
 + Instantiated template also for Debtags::Package* item type
   (still waiting for a way to avoid having to explicitly instantiate templates
    for any possible future usage)
--- 2004-06-16
 + Implemented InputMerger::getRelatedItems
--- 2004-05-13
 + Moved TagCollection::Change to TagcollChange
 + Implemented InputMerger::applyChange


 * Version 0.5

---
 + Templatize more of the consumer/filter process
 + TagCollection: add an output(consumer) method to dump the collection to a
   consumer
 + TagCollection: add a mergeEquivalenTags method
	If a tree node has only one child non-leaf node, compress them in a single
	one merging the tree tags.
	For example: /a/b/ could become /a,b/
 + Implement CleanSmartHierarchyNode
 + Implement noise reduction (remove tags with cardinality less than a given
   threshold)



*** Old tagcoll news

New in version 0.16

 - Added noise filtering
 - Added cleanhiearchy option, to merge equivalent tags in every node of the hierarchy

New in version 0.14

 - Ported to libtagcoll 0.4

New in version 0.13

 - Parser can now parse lines in the form:
   	item1, item2, item3: tag1, tag2, tag3
 - Added --group-items switch
 - Added taggrep

New in version 0.12

 - Added the "reverse" command and the --untagged-tag option.  Now it's
   possible to do this:
   	tagcoll reverse collection-file | grep ^tag:
 - Added the the --derived-tags-from option.  Not it's possible to do this:
	userlevel::novice: !specialized && (interface::gui || interface::curses)

New in version 0.11

 - Moved TCAlgo.* to SmartHierarchy.*
 - Smart hierarchies are now computed on-demand: the output of the "hierarchy"
   command starts flowing before ending the computation
 - Added the --flatten-threshold option
 
New in version 0.10

 - Fixed a commandline parsing bug that prevented --implications-from to be used
 - Implication expansion didn't include the input tag

New in version 0.9

 - Hopefully final reorganization of commandline switches (breaks existing scripts!)
 - Added the "related" command to find items related to an item or a group of items

New in version 0.8

 - Removed grave parser bug
 - Reversed the order of items in the NEWS file

New in version 0.7

 - Parser updated to accept ':' in item names and ',' in tag names

New in version 0.6

 - Big code refactoring
 - Implications now work recursively
 - Implication compression is now the default, and removes all redundancy
 - Commandline switches reorganized (breaks existing scripts!)

New in version 0.5

 - Added --patch-with
 - Added --diff

New in version 0.4.1

 - Fixed some -Wall warning

New in version 0.4

 - Added --explicit-implications
 - Added --copy
 - Added --pack
 - Added --rename-tags-from
 - Merges input lines with the same item name

New in version 0.3

 - Renamed the package in tagcoll
 - Added a commandline parser
 - Added the --show-implications function

New in version 0.2

 - A bug in the new implementation of the sorter algorithm was generating wrong
   hierarches: fixed.


*** Old libtagcoll news

 * New in version 0.6

--- 2004-05-20
 + Instantiated template also for Debtags::Package* item type
   (still waiting for a way to avoid having to explicitly instantiate templates
    for any possible future usage)
 
--- 2004-06-16
 + Implemented InputMerger::getRelatedItems

--- 2004-05-13
 + Moved TagCollection::Change to TagcollChange
 + Implemented InputMerger::applyChange
 + Implemented InputMerger::getRelatedItems
 

 * New in version 0.5

--- 2003-07-18
 + Templatized more of the consumer/filter process
 + TagCollection: added an output(consumer) method to dump the collection to a
   consumer
 + TagCollection: added a mergeEquivalenTags method
   If a tree node has only one child non-leaf node, compress them in a single
   one merging the tree tags.
   For example: /a/b/ could become /a,b/
 + Implemented CleanSmartHierarchyNode
 + Implemented noise filtering
--- 2003-07-17
 + Misc bug fixes


 * New in version 0.4

--- 2003-04-24
 + Added TagcollBuilder and TagcollReverser
--- 2003-05-23
 + OpSet<T>::contains(OpSet) did return false if the two sets were equal
 + TagCollection::applyChanges: did not work with orphans and tagless change items
 + Removed Tagset: must now explicitly use OpSet<std::string>
--- 2003-05-22
 + Added iterators to TagCollection
 + Added correct #pragma interface and #pragma implementation to all source files
 + Tagset is now a typedef to a template class OpSet, providing a set with set
   operations
 + TagcollConsumer is now a template
 + Use templates where available
 + Added applyChange to TagCollection


 * New in version 0.3

--- 2003-05-22
 + Added TagCollection::getCompanionItems
 + Added TagCollection::getCompanionItemsAndTagsets
--- 2003-05-21
 + Added TagCollection::getCompanionTags
