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 "good". 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. regards, Adam ----- Original Message ----- From: "Adam R. B. Jack" <[EMAIL PROTECTED]> To: "Gump code and data" <[EMAIL PROTECTED]> 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 an > RDBMS. > ) 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 during > 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 Context > 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.') > ) continuous.py (that runs gumpy.py 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, or > ????) We could do this in workspace, and have commandline overrides, but we > need something... > ) Python code review -- how could we be more Pythonic. What Python packages > ought we use. PyUnit? PyDoc? Others? > ) So a performance analysis of Gumpy, why did the XML load slow down, why is > 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 comparing > 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 have > 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, but > teach gumpy.py if we need. > > I think I need to stop typing... > > regards, > > Adam > -- > Experience the Unwired Enterprise: > http://www.sybase.com/unwiredenterprise > Try Sybase: http://www.try.sybase.com > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
