You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Antoine Lévy-Lambert <an...@antbuild.com> on 2004/02/04 09:17:54 UTC
Build of xml-batik on gump
As you have seen from the nag mails coming from the lsd gump instance,
we are currently not able to build xml-batik on gump. [1]
I need xml-batik indirectly to build ant-xdocs-proposal, but it affects
a large part of the gump projects. [2]
Would you be so kind to fix the problem ?
Antoine Levy-Lambert
[1] http://lsd.student.utwente.nl/gump/xml-batik/xml-batik.html
[2]
http://lsd.student.utwente.nl/gump/xml-batik/xml-batik_details.html#Full+Project+Dependees
Re: Nagging the cause vs. Nagging the effect
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 5 Feb 2004, Stefano Mazzocchi <st...@apache.org> wrote:
> On 5 Feb 2004, at 09:22, Stefan Bodewig wrote:
>> I think Gumpy already collects, or at least could collect,
>> historical data for all dependency runs.
>
> how? where?
<http://lsd.student.utwente.nl/gump/gump_stats/index.html>
in particular
<http://lsd.student.utwente.nl/gump/gump_stats/project_fogfactor.html>
which contains the number of failures, pre-req failures and successful
builds. Currently it looks as if just the aggregate numbers are
preserved, but this is a start.
Stefan
Re: Nagging the cause vs. Nagging the effect
Posted by Stefano Mazzocchi <st...@apache.org>.
On 5 Feb 2004, at 09:22, Stefan Bodewig wrote:
> On Thu, 5 Feb 2004, Stefano Mazzocchi <st...@apache.org> wrote:
>> On 5 Feb 2004, at 02:17, Adam Jack wrote:
>>
>>> I've long wished that Gump could nag the 'cause' of a problem, not
>>> the 'effect', but it is (AFAICT) pretty much impossible to guess
>>> who is cause from a compile failure.
>>
>> Tell you what: there have been looooong discussing about this and
>> endless hours that I spent on the whiteboard trying to figure out
>> *where* that data can emerge out of the entire mass of data that
>> gump is either collecting or generating.
>>
>> I was still not able to find it, still not able to come up with a
>> general algorithm that would, at least, if not identify the cause,
>> at least discriminate between "causing trends" and "effected
>> trends".
>
> The way you'd do it manually is about as follows, I believe:
>
> * start with the last good build
>
> * replace one of the dependencies with its latest version at a time
> and rebuild - reiterate until the build fails.
>
> Gumpy should have enough data to do that, but the whole thing breaks
> down when Gump has been unable to build a project for weeks or even
> months as the number of changes becomes too big.
It is clear to me that we should develop a system that works "a
regime", the bootstrap process (getting enough critical mass to attract
attention) is way to complex to be automated.
But my gut feeling is that with a system that is running and has a
reasonable nag/FoG metric/heuristic, the amount of changes never become
too big because we stop them right at the beginning.
That's the beauty of continuous integration: it's a problem forecaster,
it builds your project in a much wider scope that you can't simply take
care by yourself..
[in this sense, it's like what google does when lists backlinks to a
page: that information is not available to you, page author, because
it's a property of the graph, not of the node]
>> I think the key is that the gump runs as for Gump or Gumpy do *not*
>> contain enough information. But if we had both:
>>
>> 1) the latest dependency run
>> 2) the stable dependency run
>>
>> and we had enough history of these (say a few months), I'm pretty
>> sure the data *IS* there.
>
> I think Gumpy already collects, or at least could collect, historical
> data for all dependency runs.
how? where?
> If the dependency run has been
> successful at least once, the data is supposed to be there.
>
> I realize that this is naive. 8-)
Oh, believe me, nothing is naive in regard to data emergence. Even the
slightest local trend that looks silly and obvious, could exhibit
massively great potentials if applied to a complex topology (much like
google does for hyperlinks, agora does for replies, amazon does for
shopping carts, for example)
--
Stefano.
Re: Nagging the cause vs. Nagging the effect
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 5 Feb 2004, Stefano Mazzocchi <st...@apache.org> wrote:
> On 5 Feb 2004, at 02:17, Adam Jack wrote:
>
>> I've long wished that Gump could nag the 'cause' of a problem, not
>> the 'effect', but it is (AFAICT) pretty much impossible to guess
>> who is cause from a compile failure.
>
> Tell you what: there have been looooong discussing about this and
> endless hours that I spent on the whiteboard trying to figure out
> *where* that data can emerge out of the entire mass of data that
> gump is either collecting or generating.
>
> I was still not able to find it, still not able to come up with a
> general algorithm that would, at least, if not identify the cause,
> at least discriminate between "causing trends" and "effected
> trends".
The way you'd do it manually is about as follows, I believe:
* start with the last good build
* replace one of the dependencies with its latest version at a time
and rebuild - reiterate until the build fails.
Gumpy should have enough data to do that, but the whole thing breaks
down when Gump has been unable to build a project for weeks or even
months as the number of changes becomes too big.
> I think the key is that the gump runs as for Gump or Gumpy do *not*
> contain enough information. But if we had both:
>
> 1) the latest dependency run
> 2) the stable dependency run
>
> and we had enough history of these (say a few months), I'm pretty
> sure the data *IS* there.
I think Gumpy already collects, or at least could collect, historical
data for all dependency runs. If the dependency run has been
successful at least once, the data is supposed to be there.
I realize that this is naive. 8-)
Stefan
Re: Nagging the cause vs. Nagging the effect
Posted by Stefano Mazzocchi <st...@apache.org>.
On 6 Feb 2004, at 14:33, Leo Simons wrote:
> Stefano Mazzocchi wrote:
>> You are using an "altavista" approach of heuristical pattern
>> matching, I want to use a more Google-like approach of making human
>> inferencing emerge out of implicit topological properties of a
>> graph.
>> I have a pretty strong opinion on why the first much inferior
>> compared to the second (as google showed rather evidently, but
>> that's just the tip of the iceberg)
>
> totally agree! But altavista came around before google, and was the
> best we had at the time (coupled with the human labor of dmoz.org and
> similar). Until we figure out the "topological properties" of the gump
> graph, the "brute force" approach is better than nothing...it may save
> us some "human laboring" ;)
Oh, but look: researching this is (at least in part) my day job now :-)
--
Stefano
Re: Nagging the cause vs. Nagging the effect
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
> You are using an "altavista" approach of heuristical pattern matching,
> I want to use a more Google-like approach of making human inferencing
> emerge out of implicit topological properties of a graph.
>
> I have a pretty strong opinion on why the first much inferior compared
> to the second (as google showed rather evidently, but that's just the
> tip of the iceberg)
totally agree! But altavista came around before google, and was the best
we had at the time (coupled with the human labor of dmoz.org and
similar). Until we figure out the "topological properties" of the gump
graph, the "brute force" approach is better than nothing...it may save
us some "human laboring" ;)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
Re: Nagging the cause vs. Nagging the effect
Posted by Stefano Mazzocchi <st...@apache.org>.
On 5 Feb 2004, at 14:35, Leo Simons wrote:
> Stefano Mazzocchi wrote:
>> I think the key is that the gump runs as for Gump or Gumpy do *not*
>> contain enough information.
>
> what might work sometimes is (pattern) matching the <package/>
> statements of the dependencies against the errors produced by javac or
> unit tests, and cvs history.
>
> that would've caught the xml-batik error, I think. I mean,
>
> [javac]
> /data/gump/xml-batik/sources/org/apache/batik/script/rhino/
> BatikSecurityController.java:69:
> org.apache.batik.script.rhino.BatikSecurityController is not abstract
> and does not override abstract method
> callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.mozi
> lla.javascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla.j
> avascript.Scriptable,java.lang.Object[]) in
> org.mozilla.javascript.SecurityController
> [javac] public class BatikSecurityController extends
> SecurityController {
>
> is clearly showing to any human programmer that whatever produces the
>
> org.mozilla.javascript
>
> package is the problem, since BatikSecurityController.java presumably
> didn't change since the previous build yet started causing a
> compilation failure.
>
> you'd need to be pretty intelligent about parsing the error message
> though. But it seems to be there in some way, without needing /that/
> many statistics.
You are using an "altavista" approach of heuristical pattern matching,
I want to use a more Google-like approach of making human inferencing
emerge out of implicit topological properties of a graph.
I have a pretty strong opinion on why the first much inferior compared
to the second (as google showed rather evidently, but that's just the
tip of the iceberg)
--
Stefano.
Re: Nagging the cause vs. Nagging the effect
Posted by Stefano Mazzocchi <st...@apache.org>.
On 5 Feb 2004, at 15:32, Antoine Lévy-Lambert wrote:
> Leo Simons wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> I think the key is that the gump runs as for Gump or Gumpy do *not*
>>> contain enough information.
>>
>>
>> what might work sometimes is (pattern) matching the <package/>
>> statements of the dependencies against the errors produced by javac
>> or unit tests, and cvs history.
>>
>> that would've caught the xml-batik error, I think. I mean,
>>
>> [javac]
>> /data/gump/xml-batik/sources/org/apache/batik/script/rhino/
>> BatikSecurityController.java:69:
>> org.apache.batik.script.rhino.BatikSecurityController is not abstract
>> and does not override abstract method
>> callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.moz
>> illa.javascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla
>> .javascript.Scriptable,java.lang.Object[]) in
>> org.mozilla.javascript.SecurityController
>> [javac] public class BatikSecurityController extends
>> SecurityController {
>>
>> is clearly showing to any human programmer that whatever produces the
>>
>> org.mozilla.javascript
>>
>> package is the problem, since BatikSecurityController.java presumably
>> didn't change since the previous build yet started causing a
>> compilation failure.
>>
>> you'd need to be pretty intelligent about parsing the error message
>> though. But it seems to be there in some way, without needing /that/
>> many statistics.
>>
> What I also find interesting is that - once you have analyzed the
> circumstances which led to the failed build - there is then a period
> where you need to discuss with the various parties involved.
>
> In that particular case there were 4 alternatives :
>
> - do nothing : then gump goes on with a large failure rate,
> - make the xml-batik guys implement quickly the new method from the
> abstract class (this was my first reaction),
> - make the rhino guys fix their stuff (this was what Adam Jack did),
> - adapt Gump, by building xml-batik against a packaged js until the
> weather becomes better (I was nearly there)
>
> Exploring these possibilitiies is not something that the computer will
> do for us.
Very very true.
At the same time, I think it is useful to discriminate between causes
and effects, so that those social decisions can be more precisely
tuned.
--
Stefano.
Re: Nagging the cause vs. Nagging the effect
Posted by Antoine Lévy-Lambert <an...@antbuild.com>.
Leo Simons wrote:
> Stefano Mazzocchi wrote:
>
>> I think the key is that the gump runs as for Gump or Gumpy do *not*
>> contain enough information.
>
>
> what might work sometimes is (pattern) matching the <package/>
> statements of the dependencies against the errors produced by javac or
> unit tests, and cvs history.
>
> that would've caught the xml-batik error, I think. I mean,
>
> [javac]
> /data/gump/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java:69:
> org.apache.batik.script.rhino.BatikSecurityController is not abstract
> and does not override abstract method
> callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.mozilla.javascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.Object[])
> in org.mozilla.javascript.SecurityController
> [javac] public class BatikSecurityController extends
> SecurityController {
>
> is clearly showing to any human programmer that whatever produces the
>
> org.mozilla.javascript
>
> package is the problem, since BatikSecurityController.java presumably
> didn't change since the previous build yet started causing a
> compilation failure.
>
> you'd need to be pretty intelligent about parsing the error message
> though. But it seems to be there in some way, without needing /that/
> many statistics.
>
What I also find interesting is that - once you have analyzed the
circumstances which led to the failed build - there is then a period
where you need to discuss with the various parties involved.
In that particular case there were 4 alternatives :
- do nothing : then gump goes on with a large failure rate,
- make the xml-batik guys implement quickly the new method from the
abstract class (this was my first reaction),
- make the rhino guys fix their stuff (this was what Adam Jack did),
- adapt Gump, by building xml-batik against a packaged js until the
weather becomes better (I was nearly there)
Exploring these possibilitiies is not something that the computer will
do for us.
This is the exciting bit, which explains the sentence "Gump is a social
experiment" on the Gump web page.
Cheers,
Antoine
Re: Nagging the cause vs. Nagging the effect
Posted by Leo Simons <le...@apache.org>.
Stefano Mazzocchi wrote:
> I think the key is that the gump runs as for Gump or Gumpy do *not*
> contain enough information.
what might work sometimes is (pattern) matching the <package/>
statements of the dependencies against the errors produced by javac or
unit tests, and cvs history.
that would've caught the xml-batik error, I think. I mean,
[javac]
/data/gump/xml-batik/sources/org/apache/batik/script/rhino/BatikSecurityController.java:69:
org.apache.batik.script.rhino.BatikSecurityController is not abstract
and does not override abstract method
callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.mozilla.javascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla.javascript.Scriptable,java.lang.Object[])
in org.mozilla.javascript.SecurityController
[javac] public class BatikSecurityController extends
SecurityController {
is clearly showing to any human programmer that whatever produces the
org.mozilla.javascript
package is the problem, since BatikSecurityController.java presumably
didn't change since the previous build yet started causing a compilation
failure.
you'd need to be pretty intelligent about parsing the error message
though. But it seems to be there in some way, without needing /that/
many statistics.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
Nagging the cause vs. Nagging the effect [was Re: Build of xml-batik on gump]
Posted by Stefano Mazzocchi <st...@apache.org>.
On 5 Feb 2004, at 02:17, Adam Jack wrote:
> I've long wished that Gump could nag the 'cause' of a
> problem, not the 'effect', but it is (AFAICT) pretty much impossible to
> guess who is cause from a compile failure.
Tell you what: there have been looooong discussing about this and
endless hours that I spent on the whiteboard trying to figure out
*where* that data can emerge out of the entire mass of data that gump
is either collecting or generating.
I was still not able to find it, still not able to come up with a
general algorithm that would, at least, if not identify the cause, at
least discriminate between "causing trends" and "effected trends".
I think the key is that the gump runs as for Gump or Gumpy do *not*
contain enough information. But if we had both:
1) the latest dependency run
2) the stable dependency run
and we had enough history of these (say a few months), I'm pretty sure
the data *IS* there.
Somewhere :-)
I'm diving deeper and deeper into graph theory these days, and my gut
tells me that's where the solution resides.
Since analyzing extremely complex graphs for trends is now my day job
(and will be at least for the next few years), I'll be happy to apply
my discoveries to Gump as well, both to understand a reasonable metric
for FoG and to do a much more high quality nagging.
But, for that, we need to have both the latest and the stable
dependency runs.... so we should start thinking on how to achieve that
first.
> --
Stefano.
Re: Build of xml-batik on gump
Posted by Adam Jack <aj...@TrySybase.com>.
> You might try nagging rhino as it was their change that caused
> the problem - if they can give us an upwards compatible solution
> I'll use it (the basic issue is that they added a method to an
> interface that uses a class that didn't exist in the version of rhino
> we are currently using).
This is a valid point. I've long wished that Gump could nag the 'cause' of a
problem, not the 'effect', but it is (AFAICT) pretty much impossible to
guess who is cause from a compile failure. It is quite possible that the
Rhino folks aren't aware of the problem this has caused, and they might be
open to re-working things.
Is there a Rhino mailing list anywhere? I don't see one here:
http://www.mozilla.org/rhino/
regards
Adam
Re: Build of xml-batik on gump
Posted by Antoine Lévy-Lambert <an...@antbuild.com>.
Thomas de Weese of the xml-batik team has answered my email :
http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03836.html
* /Subject/: _Re: Build of xml-batik on gump_
* /From/: *Thomas DeWeese <Thomas.DeWeese@Kodak.com
<ma...@Kodak.com>>*
* /Date/: /Wed, 04 Feb 2004 08:55:03 -0500/
* /To/: /batik-dev@xml.apache.org <ma...@xml.apache.org>/
------------------------------------------------------------------------
Antoine Lévy-Lambert wrote:
> As you have seen from the nag mails coming from the lsd gump instance,
> we are currently not able to build xml-batik on gump. [1]
> I need xml-batik indirectly to build ant-xdocs-proposal, but it affects
> a large part of the gump projects. [2]
>
> Would you be so kind to fix the problem ?
I would however we are about to do a 1.5.1 release of Batik,
and the change in Rhino would require us to bundle a new js.jar
which I don't want to do right before a release.
You might try nagging rhino as it was their change that caused
the problem - if they can give us an upwards compatible solution
I'll use it (the basic issue is that they added a method to an
interface that uses a class that didn't exist in the version of rhino
we are currently using).
> Antoine Levy-Lambert
>
> [1] http://lsd.student.utwente.nl/gump/xml-batik/xml-batik.html
>
> [2]
> http://lsd.student.utwente.nl/gump/xml-batik/xml-batik_details.html#Full+Project+Dependees
>
Re: Build of xml-batik on gump
Posted by Thomas DeWeese <Th...@Kodak.com>.
Antoine Lévy-Lambert wrote:
> As you have seen from the nag mails coming from the lsd gump instance,
> we are currently not able to build xml-batik on gump. [1]
> I need xml-batik indirectly to build ant-xdocs-proposal, but it affects
> a large part of the gump projects. [2]
>
> Would you be so kind to fix the problem ?
I would however we are about to do a 1.5.1 release of Batik,
and the change in Rhino would require us to bundle a new js.jar
which I don't want to do right before a release.
You might try nagging rhino as it was their change that caused
the problem - if they can give us an upwards compatible solution
I'll use it (the basic issue is that they added a method to an
interface that uses a class that didn't exist in the version of rhino
we are currently using).
> Antoine Levy-Lambert
>
> [1] http://lsd.student.utwente.nl/gump/xml-batik/xml-batik.html
>
> [2]
> http://lsd.student.utwente.nl/gump/xml-batik/xml-batik_details.html#Full+Project+Dependees
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org