TODO:

 - Do a facet filter, to only get in packages with given facets.  It could be
	used for example to prepare the data to then create a smart hierarchy using
	only facets relevant to a given environment

 - Have the related command accept a tagset, and not just a package name, as
	the start of a search
	[ender]

 - [herv]
	> The problem is, it takes a lot of time for me to dwelve into the
	> automake info files to find out how to add to the distclean target.
	> Do you have some hint on where to look at?
	CLEANFILES = *~ .*~ *.bak *.org gmon.out core \#*\# .\#*
	in .am files. You can add that in a include file, included by every  
	Makefile.am...

 - [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.
 - Make a "best istallation candidates" option: give points to tags depending
	on how many packages are installed and have that tag.  Then sort the
	non-installed packages by tag score
	[ender]
 - Maintain an upgrade checklist for the vocabulary.  cvs diff can help
	generating it
 - 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.

 - Make TagCollection a template wrt the item format
   (I *badly* need to discover how to distribute templates inside libraries!)


*** Done in tagcoll 1.0

--- 2004-07-25
 + Ported to libtagcoll 1.0

*** 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]


 vim:set ts=3 sw=3: