RT is where you throw you thought in the mix and see what happens. It could be the best thing or the most silly idea.
this is a good one. Summary of some important thoughts so far.
Gump social maintenance costs are still too high on the gumpmaisters and not well distributed horizontally across the various projects.
indeed. Gump as a social experiment takes its toll on the experimentors.
As I said previously, gump is just too verbose. Beside gump own developers, Gump is the kind of web site that you look at only when there are problems.
you know, I'm inclined to design a 'mock' workflow package here, conduct tests of people's behaviour, improve the mock, etc. The gump workflow is *complex*.
Not that I actually know much about user interface testing ;)
at this point I'll let the discussion start on what should be on that page.
we need guinea pigs :-D
= Workflow =
let's try to describe the optimal gump workflow. I've found (in describing this to other people), that the current gump workflow is much like working on (someone else's) spagetti code. It seems we need the equivalent of "code insight" features.
How would that work? Send me an e-mail saying my project failed to build. Include a link that will take me to the (highlighted) part of the build output that seems to be the problem. Make references to classnames 'n stuff clickable. Clicking on a classname (ie as spit out by the compiler when there's a problem) takes me to the build log of the dependency.
If another project failed because of my change, send me an e-mail pointing to that failure (those failures). Indicate the classes that seem to be the problem. Tell me when the project started failing and provide me a ViewCVS link that indicates the class that is apparently causing problems for the other project.
As a first step, let people look at the cvs history themselves. Automation seems nice, but there's also a lot that can be done just by making the UI as powerful as possible.
But since we're going by leaps and bounds right now...we need a wiki-style workflow. Ditch CVS and provide me with an "edit this descriptor" page. The task of finding the right descriptor to edit can be several minutes of work. That should change to several seconds.
= The Human Factor =
What I really like about gump is the principle that we emulate developer behaviour as much as possible.
We could just let the metadata point to the sources, do away with ant alltogether, and implement an IDE-like compiler. But then gump would be able to build lots of things that might fail to build on the commandline.
= The friggin' broken buildsystem =
It's not always a classfile change that broke things. In the avalon case, for example, the projects that are failing to build haven't seen very significant API change. The build itself is broken.
Maybe we should fall back to trying a non-ant build when that happens. Is it possible to detect an ant (or maven) failure as opposed to an api change? Is it worthwhile to seperate it out.
= Let's go relational =
We want to build a complex, flexible, relational model of all these builds. Maybe its just me, but XML doesn't express that too well. It's much easier to express some fomrs of "intelligence" in SQL.
Enough brainstorming for tonight.
I have more to say, but gotta run right now :-D
-- cheers,
- Leo Simons
----------------------------------------------------------------------- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles & Opinions -- http://articles.leosimons.com/ ----------------------------------------------------------------------- "We started off trying to set up a small anarchist community, but people wouldn't obey the rules." -- Alan Bennett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
