gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@trysybase.com>
Subject Fw: Moving Gump Forward (Feedback)
Date Wed, 10 Mar 2004 19:40:29 GMT
I'm told I was posting HTML from this account, sorry.

Leo, I am very interested in seeing a webapp interface to Gumpy [to
relational or not], so if you need (want) help tying something into the
'back end' (existing code) I'll happily work w/ you.

regards,

Adam
----- Original Message -----
From: "Adam Jack" <ajack@trysybase.com>
To: <general@gump.apache.org>
Sent: Wednesday, March 10, 2004 11:02 AM
Subject: Moving Gump Forward (Feedback)


>>From this thread:


http://nagoya.apache.org/eyebrowse/BrowseList?listName=general@gump.apache.o
rg&by=thread&from=667384

.. here are my thoughts, (for what they are worth).

Stefano has convinced me that pure numbers are not the most erudite form of
communication, are equivocable (folks will hate the algorythms) and could be
contentious & have negative impacts. I would like to find a replacement,
perhaps visual, form. I don't want to promote numbers for number sake, nor
be involved in undermining people's efforts via some crude raw value. That
said, until we have a better solution I'm game to keep putting out numbers,
but leave the interpretation to individuals.

Further, numbers don't give sufficient insights into the issues affecting a
branch (or a deeply product). This is huge, I agree. I don't think we truely
know the "chances" of getting a clean Gump build. We know what stopped this
one, but we don't really know what allignment of the planets will get us to
a full build. We need to (somehow) analyze the branches (as sub-trees) and
express information for them.

I am not convinced that we *need* to get inside build results to determine
exactly what caused what, but I like the idea (acadaemically) and am willing
to work with folks to attempt it.

Stefan has convinced me that folks builds need to be complex, and deserve
"community scrutiny" also, so I'm all for keeping <ant as the primary build
tool. [I keep thinking that some projects really ought be just a simple,
compile/jar/test, but I'm not convinced that it is enough to try it any time
 soon.] That said, I do think we need to make our metadata slightly more of
a project descriptor, and not an 'ant' descriptor (describing only
inputs/outputs.) I think that if we knew that the data (source code) for
project X is in directory Y, we'd be in a better prosition for extensions.

Leo has convinced me that the workflow is too difficult and a nice
(web-based) UI is important. With that I don't see the need for relational
metadata, and I personally prefer to avoid it (for now) to allow for easier
extensibility. If we hide the XML I'd prefer to keep it, but I could as
easily work with SQL, so am ambivalent.

Basically, I like the input so far, it is refreshing. If folks have time for
more I'd love to hear more about how Gump can mine it's metadata to generate
new information (such as inter-relationships between projects, 'distance'
between groups, trends, etc.) but maybe that is a little too far out there.

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message