gecko-dev/webtools/tinderbox2/Todo

I did not code a warnings system with all the warning pages (see
tinderbox1). I am not sure this belongs in Tinderbox proper.  I think
that a separate webscript running a version of "lint" would be a
better choice.  This web script would be a tinderbox "build".  This
would totally decouple the warning system from the tinderbox error
parser and provide more robust warnings then a traditional
compiler. IF we need to put it in Tinderbox we should create a special
library which is called every time the error parser detects a warning.

I need a Javascript expert to look over the current versions of CVS
Blame and Tinderbox1 and ensure that I have the best features of these
javascript programs in tinderbox2/src/lib/HTMLPopUp/MozillaLayers.pm.
Please keep the code neat and nicely indented.

I need to allow the VC system to have a daemon gather the VC
information and pass it to tinderbox via the same update methods which
Builds uses. Then both the tinder.cgi and this new cvs process could
be run out of cron periodically and the webpages would not be delayed
if CVS takes a long time to respond this might improve the response
time of the web updates.  Also the OS process scheduler could do a
better job of scheduling if there were two different processes one
which was IO bound and one which was CPU bound.  

It would be really nice if CVS could mail tinderbox the updates which
apply to the branches of interest, then tinderbox would not have to
poll and it would get the branch information which it needs.

I would be interested in a module VCDisplay module to work with this
bonsai work alike tool http://viewcvs.sourceforge.net/ but I do not
have time not to investigate it. This should be simple to code once
viewcvs is setup, it may even be exactly the same as
VCDisplay::Bonsai.

I had one user who used the new Perforce modules but they reported
problems with the data gathering capability.  They did not give me
enough info to fix the problem. Any help here would be apreciated.
VCDisplay::Perforce_P4DB appears to work.

I would like to have a compression library which can be used to
compress and uncompress logs so that the transit of those logs is
compressed.  The difficulty here is that the library should be
flexible.  Perhaps the build machines do not have the perl compression
libraries but do have the compression binaries it may be the reverse
situatuation on the server.  Also We should support many kinds of
compression/encryption (uuencode, ascii armor) and other data
transforms so that users can configure the mail to use compression
followed by pgp followed by ascii armor or something like that.