Re: Gump

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

Hunsberger, Peter wrote:

> Stefano Mazzocchi <st...@apache.org> writes:
> 
> <snip/>
> 
>>I have a RT ready for gump that would allow to solve these 
>>issues... but 
>>I need to work more on this since it appears to be a pretty tough 
>>computational problem of graph analysis.
> 
> 
> We do have generalized hedge generator code (both in a Cocoon sense and
> in a flat query to data structure sense) that I might be able to get you
> a copy of ;-)...  However, I suspect you need the opposite of what we
> have; something to break down tree structured data into hedges and look
> for intersections (cycles)?

oh, nono, the problem is completely different: when a project doesn't 
compile, who's fault is that?

Currently gump has information such as

  (A) --(depends on)--> (B)

the problem with this is that if A breaks, it could be because of B's 
fault or because of A's fault, you can't tell.

What I'm going to propose is to have bidimensional dependencies:

  (A,20040302) --(depends on)--> (B,20040212)

At this point, gump can do multiple builds based on the timestamp and it 
is possible figure out who broke what and when, in theory point at the 
very single commit to blame.

The problem is that the complexity of such trellis grows very big very 
quickly. I still have to understand if it's duable at all!

-- 
Stefano.

Re: Gump

[Berin Lautenbach <be...@wingsofhermes.org>]

Stefano,

One of the things I have been playing with in the C builder is the idea 
of identifying official releases.

So as an example, xml-security-c depends on Xerces-c and Xalan-c.  So 
for xml-security-c I do three builds :

- Xerces-c cvs, Xalan-C cvs and Xml-security cvs (bleading edge)
- Xerces-c 2.5, Xalan-C 1.7 and Xml-security cvs (current official 
release of Xerces and Xalan combined with xml-security from CVS)
- Xerces-c 2.3, Xalan-C 1.6 and Xml-security cvs (n-1 official release 
against CVS).

For Xerces-c and Xalan c, I keep a compiled copy of the last 2 versions 
(n and n-1) and use LD_LIBRARY_PATH and configure options to compile 
against the correct version.

By only going n-1 I keep the complexity reasonably low, and by keeping 
compiled versions I don't waste cycles doing re-builds of "static" versions.

What I *don't* do, is pick any arbitrary dates when something last 
built.  The reason being I only want to build against something that the 
owners of the dependencies "certified" as being OK.

Note the problem domain here is a bit simpler, as a particular version 
of Xalan-C is only really supposed to work with a particular version of 
Xerces-C.

Idle thoughts, but maybe useful.

Cheers,
	Berin

Stefano Mazzocchi wrote:

> Hunsberger, Peter wrote:
> 
>> Stefano Mazzocchi <st...@apache.org> writes:
>>
>> <snip/>
>>
>>> I have a RT ready for gump that would allow to solve these issues... 
>>> but I need to work more on this since it appears to be a pretty tough 
>>> computational problem of graph analysis.
>>
>>
>>
>> We do have generalized hedge generator code (both in a Cocoon sense and
>> in a flat query to data structure sense) that I might be able to get you
>> a copy of ;-)...  However, I suspect you need the opposite of what we
>> have; something to break down tree structured data into hedges and look
>> for intersections (cycles)?
> 
> 
> oh, nono, the problem is completely different: when a project doesn't 
> compile, who's fault is that?
> 
> Currently gump has information such as
> 
>  (A) --(depends on)--> (B)
> 
> the problem with this is that if A breaks, it could be because of B's 
> fault or because of A's fault, you can't tell.
> 
> What I'm going to propose is to have bidimensional dependencies:
> 
>  (A,20040302) --(depends on)--> (B,20040212)
> 
> At this point, gump can do multiple builds based on the timestamp and it 
> is possible figure out who broke what and when, in theory point at the 
> very single commit to blame.
> 
> The problem is that the complexity of such trellis grows very big very 
> quickly. I still have to understand if it's duable at all!
> 

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