Moving Gump Forward (Feedback)

[Adam Jack <aj...@trysybase.com>]

>From this thread:

    http://nagoya.apache.org/eyebrowse/BrowseList?listName=general@gump.apache.org&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

Re: Moving Gump Forward (Feedback)

[Stefano Mazzocchi <st...@apache.org>]

Adam Jack wrote:

> From this thread:
> 
>     http://nagoya.apache.org/eyebrowse/BrowseList?listName=general@gump.apache.org&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. 

Glad to hear that.

> 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.

It is possible to follow a regexp patter matching to identify and 
extract potential information from the build result, the build results 
are machine-generated so they are structured enough to be parsable and 
unlikely to change too fast.

Scraping is a weak practice for individuals, but it's a viable solution 
if you can divide labor with no bottlenecks (see spam-assassin, for example)

> 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.

also keep in mind the need to keep gumpy language-agnostic, or we can't 
build HTTPD.

> 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.

I think that even simply modifying the xml in a browser text area and 
have that fed back would be a nice step forward.... but security is the 
big concern here as infrastructure doesn't like applications to be able 
to commit directly to CVS.

> 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.

Let's keep talking about it, ideas will pop up.

-- 
Stefano.