>From this thread:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&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
