Danny Angus wrote:
You have to define what is the "World" that you want to integrate.
In GUMP's case it is the world of Open Source.
The problem is that you define that CI IS GUMP, while this is not the
only truth. I can agree that GUMP is a Continuos Integration tool, but
configured the way ASF did it is not so useful to James Project as CI
could be.
We don't need nightly builds, we need a better CI. I don't care if we
want to keep or remove the current gump, I'm only saying that we need
Continous Integration for the James project: this mean that it should
integrate james products and nothings else, and should test things and
produce results (nightly builds, reports).
I personally don't care if commons-collection create a new jar that will
not work with James. Instead I would like to know if jspf or postage
starts being incompatible with the latest trunk.
Thats a project level thing though, GUMP is about the bigger picture.
Well it seems to me that this is what the ASF GUMP installation IS, not
what GUMP is. Btw I don't know GUMP enough to be sure of this. I'm
really sure that the definition of Continous Integration is not that you
have to integrate the entire world of dependencies.
Just search the internet for some definition of "Continuous Integration"
and you will find many references to "integration of many modules of a
project" or as raw as the Wikipedia definition: "Continuous integration
is a software engineering term describing a process that completely
rebuilds and tests an application frequently"
Furthermore when (if) we'll move to multi-module for james it will also
test the integration between the modules.
And I don't really want to have my builds broken by non-working velocity
as we don't use it and don't need it.
I know, and the answer is "thats not what GUMP is for"
That's why I never said that we should use GUMP ;-).
I always thought to run continuum for that... I don't know why the
thread bring us to GUMP...
About our nightly build we currently don't run unit-tests before
creating them, we don't create reports, we don't publish other
informations. It would really better to have such things done.
Agree, for which we need to have proper nightly builds.
We probably don't share the definition of nightly builds, because I
think that we need CI for James products inside the James project.
We need to build, test, produce reports for all of our artifacts. This
is better defined as CI than by Nighly Builds (IMO).
I don't care about defining what CI is or is not,
No but the GUMP people do!
Ok, I will never say GUMP in the future ;-)
but I care about results:
Fair enough. But that means you want nightly builds and not CI
I don't agree.. but maybe we can talk about "we need what bago define CI
and danny define nighly builds".. the important thing is that we now
have a way to understand each other..
I don't need to test the latest velocity, but I really need a
continous build (maybe done each hour or less) that run a full
build/test/report generation/packaging and alert me if something goes
wrong.
Ok then we need a CI build internal to the project, Maven and
cruisecontrol work exceedingly well to do this, we have over 20 maven
build on a continuous loop with cruisecontrol here, and it takes just
about zero admin.
Exactly what I had in mind. What I want to know is if ASF already
provide infrastructure for this or if we have to do this ourselves. In
the latter can I don't care about cruisecontrol vs continuum: the one
that will setup the things will decide what to use.
Currently if I commit something that builds but break tests no one
notice this: this is not good.
Agreed. I only said that GUMP is not the answer.
d.
Then you were talking to Noel and I thought you were talking to me.
:-)
Stefano
