History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CIB-1338
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Daniel Ostermeier
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Pulse

Allow the project reports to display custom data.

Created: 25/Nov/07 11:37 PM   Updated: 11/Dec/08 05:48 AM
Component/s: Reporting
Affects Version/s: None
Fix Version/s: x.x


 Description  « Hide
It would be very useful if custom information could be displayed on the Reports tab.

Since what is of interest varies from project to project / person to person, we need to support a configurable form of data extraction. A custom post processor is a good option for this.

Once we have the custom data, we need to support the configuration of the graphs to allow the desired data to be displayed.

 All   Comments   Change History      Sort Order:
Chris McEvoy - 26/Nov/07 12:37 PM
Speaking for projects I work with on a regular basis, I would be interested in this feature to chart application performance, code size, and other numbers over time. For example, I would like to see how memory use of my application changes from build to build when running my automated test suite. Specifically, I would record and graph the number of megabytes allocated for each run.

I am interested in graphs where the X axis is time or builds, and the Y axis is some number I extract from tty output. The custom post processor could be used to extract one number per build invocation per custom graph. The graph should automatically scale on the Y axis to fit the data. The graph should have a user specified title. Perhaps I can select between line graph and bar graph, although this is less important for me.

There might be many custom graphs. It may be useful to provide a method of displaying a subset of graphs at a time on the web page.

Daniel Ostermeier - 11/Dec/08 05:48 AM
Trying to clean things up a little. We currently have a couple of very large buckets of tasks that are really not indications of our scheduling. What I am doing is for starters, moving all of the 2.x. items into x.x to indicate that they have not been scheduled. We can later go through these and pick up with ones that we intend to complete for an upcoming release.