gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: Stuff TODO
Date Thu, 01 Apr 2004 21:41:36 GMT
Sam's recent posting reminded me of a couple more:

1) A page comparing the entities where a status differs (on the N servers
any Gump is aware of). No guarantees that this is an environmental problem
(it could be timing) but it'd be a nice 'dashboard'.

2) Create a GumpAssistant (a GumpMeister's MiniMe :-) to review the results
(like this above) and look for issues. I don't think we (currently) have the
technology [or process knowledge] to trim the pages to 'just what we need to
know', but I think we can have something (a page, and e-mail, whatever) try
to highlight interesting things.

The sort of things this could identify (for starters is):

1) Which are the top N project that if we fixed them, we'd do the most
2) What projects are in error, and have sat that way for too many runs?
3) What projects are (repeatedly, we could add 'duration in state' to
server.xml) failing on one server, but not all.
4) Do we have any metadata (even XML format) errors? [We need to turn
annotations into something coded, not for language sensitivity (as of yet),
than automated processing.]
5) Do we have any broken packages (they ought only be environmental) or
broken non-build projects (metadata).
6) Newcomers (tell us first time projects)

... stuff like this.


----- Original Message ----- 
From: "Adam R. B. Jack" <>
To: "Gump code and data" <>
Sent: Thursday, April 01, 2004 10:33 AM
Subject: Stuff TODO

> These ought get added to JIRA, and I'll try to find time for the bigger
> ones, but off the top of my head -- here is a wishlist. I'd love folks to
> take on different tasks and I'd help them w/ my knowledge of current
> internals, if needed, etc.
> In no particular order:
> ) An historical results database of results (per project, per module?) in
> ) Dated log (but with RSS/Atom/results.xml above that, not dated.)
> ) xdocs written into log, not launch forrest, for tomcat (based
> off --xdocs). [There might be dragons here.]
> ) Writing entity (work/files/project/module/workspace) documentation
> the run.
> ) Complete replacement of license headers with AL 2.0, see
> ./python/license.txt
> ) Find all :TODO: in code, and evaluate, perhaps log in JIRA
> ) Review of the RSS/Atom generation, to see if the hierarchy of channels
> makes sense.
> ) Move run information (like annotation/state/etc) off the model entities
> (which are already parallel to the XML entities) perhaps to parallel
> objects, e.g. ProjectContext -> Project -> XMLProject. This is so GUI
> (others) can reuse the load Workspace model.
> ) An --optimise (that only builds if isUpdated [from CVS|SVN] is true)
> ) A --nonag (an override to suppress nagging)
> ) An --official (to say 'produce results/nag/etc.')
> ) (that runs within a loop, with some --optimise -- 
> nonag, some --official). Perhaps same for a continuous 'check' loop.
> ) Configuration .... this one is huge. We have some cheap commandLine code
> that sets values into a GumpRunOptions object, but we probably want a more
> sophisticated configuration approach (a config.xml that spans workspaces,
> ????) We could do this in workspace, and have commandline overrides, but
> need something...
> ) Python code review -- how could we be more Pythonic. What Python
> ought we use. PyUnit? PyDoc? Others?
> ) So a performance analysis of Gumpy, why did the XML load slow down, why
> the dictionary accessor in the XML object get called so much, where is all
> the memory going? etc.
> ) E-mail -- cope with full unicode addresses (e.g. Ceki Gulcu's in log4j)
> ) SVG -- some nice 'charts|graphics' generated as x.svg and access (via
> forrest) as x.png.
> ) An HTML Documenter, via Cheetah.
> ) Better FOG math, especially statistical analysis
> ) depend=all (for Nicola to have his project run last of all.)
> ) 'Peers' -- calculating projects with identical dependencies (for
> FOG)
> ) 'Obstacles' -- calculating which project (not just root cause) block a
> successful run for this project.
> ) Have a CVS tag (or branch?) for LIVE Gump and TESTING Gump, so we can
> production runs, and yet feel comfortable extending the code. I don't know
> if we just chose this when we checkout, and an update will get the same,
> teach if we need.
> I think I need to stop typing...
> regards,
> Adam
> --
> Experience the Unwired Enterprise:
> Try Sybase:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message