You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/04/21 12:59:30 UTC
[RT] Improving on gump
Adam R. B. Jack wrote:
>>+Currently our [http://lsd.student.utwente.nl/gump/#Project+Summary
>
> success rate]
>
>>+is 75.34% with 592 projects.
>
>
> It got into the 80s until one sole unit test in one project brought a bunch
> of stuff tumbling down, and it hasn't been fixed. :(
>
> Personally, I'm starting to but that we ought to gump on latest gump
> produced jars (so deeper project get a shot at (at least) finding their own
> mistakes, or ones they cause others). Other than technically (how to do
> this, or that this is imperfect) did any serious opposition occur to this
> idea? Pointer to a thread would be welcomed, as would a 'design decision'
> entry in the wiki...
I'm in a ISO meeting so I don't have much time, but I so much would like
us to start using gump in two ways:
1) as continuous integrator
2) as nighly build tool
the difference is that when Project A depends on Project B, the
continuous integration mode does
get latest B
build it
if successful {
get latest A
build it
if successful {
// do nothing since everything is cool
} else {
send email to A
}
} else {
send email to B
}
Now, the problem with this approach is that if B is broken, we have no
way to help A until all the dependencies have been fixed. While the
principle of continuous integration is *outstanding* and probably the
biggest improvement in software development in a decade, I think that
should not preclude other uses of the software.
So, my proposal is to use Gump like this:
get latest B
build it
if successful {
get latest A
build it against latest B
if successful {
// do nothing since everything is cool
} else {
send email to A (
with results from A build
)
}
} else {
get B that A says it depends on (out of timestamp)
build it
if successful {
get latest A
build it against dependent B
if successful {
send email to B (
with the results from latest B built
)
} else {
send email to A (
with results from A built
with list of broken dependencies
)
} else {
send email to A copying B (
with results to targetted build
)
}
}
This can be done with computational feasibility because it downgrades
only when necessary (and shouldn't be much at regime) and the advantage is:
1) more precise nagging (we can now understand who broke what, just
can't estimate when (yet!))
2) projects that are disconnected by a breakage can still receive
feedback on what they are doing (critical for complex projects like cocoon!)
the only thing missing is that our current project metadata doesn't
contain information on what tag/timestamp the project is dependent on,
but we can start adding that information incrementally, or let projects
know that this ability is available and they will fly to update their
descriptor files!
Comments?
--
Stefano.
Re: [RT] Improving on gump
Posted by Leo Simons <ls...@jicarilla.org>.
Stefano Mazzocchi wrote:
> sorry for the delay, I'm so behind my email it hurts!
<snip/>
> It concerns me that people are very silent about this.
see above :-D. The ideas are good. I'm just working to get enough python
knowledge under the belt to be able to contribute a little more than
just ideas and metadata.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Improving on gump
Posted by Nick Chalko <ni...@chalko.com>.
Stefano Mazzocchi wrote:
> Stefan Bodewig wrote:
>
> sorry for the delay, I'm so behind my email it hurts! Crete was
> wonderful though ;-)
>
> It concerns me that people are very silent about this. Did I go to far?
>
I love the idea, But I would implement it with out the emails first,
Then add the emails one at a time. I am unsure of our abailbity to
assign "blame", that may be implied in some of the emails.
R,
Nick
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Improving on gump
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 28 Apr 2004, Stefano Mazzocchi <st...@apache.org> wrote:
>>> get B that A says it depends on (out of timestamp)
>>> build it
>> against which versions of B's dependencies? dated or latest?
>
> uh, recursion, gosh, didn't think about that. What would you
> suggest?
Avoid recursion. 8-)
We are already in the "HEAD of B doesn't build" branch here. This
means the whole algorithm has already been tried for B before - since
we've already tried to build B before.
When we fall back to a dated B, we should also fall back to dated
dependencies of B IMHO, unless those dependencies are also declared
dependencies of A. So if B depends on C date X and A depends on C
date Y, we should try to build A against B HEAD plus C HEAD and if
that fails against B dated plus C HEAD (and maybe even retract to B
dated plus C Y). If A doesn't explicitly depend on C, use C date X
right away when building against the dated B.
Hmm, maybe the algorithm you describe is tackling the process from the
wrong side. A may have many dependencies, so it should be more of
something like
we want to build A
loop through all dependencies of A - those have been (tried to get)
built already
foreach dependency D
if build has been successful {
add "D HEAD" to the things we will use during build of A
} else {
send mail to A
add "D dated" to the things we will use during build of A
}
}
build A HEAD against the set just collected
if failed {
send mail to A
...
the difficult part in the presence of multiple dependencies
the following is the most simple algorithm that allows us to
build as much as possible without getting lost in combinatorics.
Looks like what Nick suggested.
...
replace all "HEAD" versions in the dependency set with "dated"
rebuild A
if successful {
send mail to A with build results, let A sort out which dependency
to blame
} else {
A's fault, they already have a mail
}
}
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Improving on gump
Posted by Stefano Mazzocchi <st...@apache.org>.
Stefan Bodewig wrote:
sorry for the delay, I'm so behind my email it hurts! Crete was
wonderful though ;-)
> On Wed, 21 Apr 2004, Stefano Mazzocchi <st...@apache.org> wrote:
>
> [nightly build like proposal]
>
>
>> get latest B
>> build it
>> if successful {
>> get latest A
>> build it against latest B
>> if successful {
>> // do nothing since everything is cool
>> } else {
>> send email to A (
>> with results from A build
>> )
>
>
> maybe copy B here?
sure
>
>
>> }
>> } else {
>
>
> send email to A with list of broken dependencies?
makes sense
>
>
>> get B that A says it depends on (out of timestamp)
>> build it
>
>
> against which versions of B's dependencies? dated or latest?
uh, recursion, gosh, didn't think about that. What would you suggest?
>
>
>> if successful {
>> get latest A
>> build it against dependent B
>> if successful {
>> send email to B (
>> with the results from latest B built
>> )
>
>
> B should have received a mail when we tried to build B already.
very true, I guess I need to reconsider this algorithm to make it fully
recursive.
>
>> } else {
>> send email to A (
>> with results from A built
>> with list of broken dependencies
>> )
>> } else {
>> send email to A copying B (
>> with results to targetted build
>> )
>
>
> why do you want to copy B if A fails to build against the very same
> version of B A claims to be compatible to?
you are right, I thought it might have been a B problem, but i think it
would generate too much noise. +1 to remove copying B
>
>
>> }
>> }
It concerns me that people are very silent about this. Did I go to far?
--
Stefano.
Re: [RT] Improving on gump
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 21 Apr 2004, Stefano Mazzocchi <st...@apache.org> wrote:
[nightly build like proposal]
> get latest B
> build it
> if successful {
> get latest A
> build it against latest B
> if successful {
> // do nothing since everything is cool
> } else {
> send email to A (
> with results from A build
> )
maybe copy B here?
> }
> } else {
send email to A with list of broken dependencies?
> get B that A says it depends on (out of timestamp)
> build it
against which versions of B's dependencies? dated or latest?
> if successful {
> get latest A
> build it against dependent B
> if successful {
> send email to B (
> with the results from latest B built
> )
B should have received a mail when we tried to build B already.
> } else {
> send email to A (
> with results from A built
> with list of broken dependencies
> )
> } else {
> send email to A copying B (
> with results to targetted build
> )
why do you want to copy B if A fails to build against the very same
version of B A claims to be compatible to?
> }
> }
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Improving on gump
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> Project A says it needs Project B version 1.5 or better. So try with
> the latest B... follow the algorithm above - the algorithm is the same
> but the actions are different. Version would just get the Jar, not try
> building from scratch and instead of sending emails, would simply
> back-off to older versions (but always 1.5 or better) and try again.
> The question is, is there a way that Depot and Gump could share an
> implementation of the algorithm, given that at the moment Depot uses
> exclusively Java and Gump is moving to exclusively Python?
My thinking has been to leverage depot-update (the repository artefact
download tool, which uses depot-version) to 'pull' the latest of an artefact
from this (or another) Gump repository. I think this could work for this
case (as well as cascading Gumps). I'm generally working towards that.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [RT] Improving on gump
Posted by Michael Davey <Mi...@coderage.org>.
Stefano Mazzocchi wrote:
>
> I'm in a ISO meeting so I don't have much time,
...and then goes on to propose a new algorithm that causes the
integration to try to "back-off" until something builds ;)
>
> get latest B
> build it
> if successful {
> get latest A
> build it against latest B
> if successful {
> // do nothing since everything is cool
> } else {
> send email...
> }
> } else {
> get B that A says it depends on (out of timestamp)
> build it
> if successful {
> get latest A
> build it against dependent B
> if successful {
> send email...
> )
> } else {
> send email...
> )
> } else {
> send email...
> )
> }
> }
[snip]
> Comments?
Kinda off-topic, but it occurs to me that Depot Version could use
essentially the same algorithm to handle versioning.
Project A says it needs Project B version 1.5 or better. So try with
the latest B... follow the algorithm above - the algorithm is the same
but the actions are different. Version would just get the Jar, not try
building from scratch and instead of sending emails, would simply
back-off to older versions (but always 1.5 or better) and try again.
The question is, is there a way that Depot and Gump could share an
implementation of the algorithm, given that at the moment Depot uses
exclusively Java and Gump is moving to exclusively Python?
I ask here and don't copy the Depot list because It seems to make sense
for Gump to take the lead if code were to be shared and because I know
that some of the Depot coders hang out here.
--
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org