gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: [RT] Moving gump forward
Date Mon, 08 Mar 2004 12:10:14 GMT
Stefano Mazzocchi wrote:
> 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 

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 

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


- Leo Simons

Weblog              --
IoC Component Glue  --
Articles & Opinions --
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett

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

View raw message