The upgrade procedure creates a column called 'started' in the milestone table,
some SQL views and functions, and some Trac reports. No external scripts are needed
to collect iteration statistics. Everything is done with SQL queries.

The plugin needs two custom ticket fields, so the following must be added to the
trac.ini file of the environment:

I did most of the development on Windows/Apache/Postgres 8.1.4/Trac 0.11.
I really have no idea if the
SQL will work on any other backend, and I doubt I'll ever find the time to test with other
setups.

I then backported to Trac 0.10. The backport changes
are actually quite trivial. In fact I left the 0.11 code commented out and ready to kick in.
I just didn't feel like creating and maintaining two different branches.

I couldn't find any way to make the Python setup utilities also build the Java applet, so I
had to use a trivial Makefile. So, to build, you should just run [n]make in the plugin
root directory. make install should deploy it. As long as Python and javac are in your path, it should work.
I did try to run Cygwin GNU make 3.80 on it, and it seems the Java target build statements upset the shell. Couldn't figure out why :-(

Download

Source

Example

Instead of entering some value that is then added to the workdone counter for a
specific ticket, users enter the actual new value. So if for a ticket the current
number of workdone hours (or whichever tracking unit you chose for your project)
is 7, and an engineer has just done 3 more hours, he should simply input 10 and
submit.

The iteration burnup chart simply groups all the tickets that currently belong
to the selected milestone, and starts plotting all changes to the the sums of
their work estimated and done values. The iteration period is marked by an
interval marker. If work has done on the tickets outside of the iteration period, then some points will be plotted outside the marked area.