Tim Vernum wrote:
>
> In general, I believe that automated build/test processes are *very*
> important, an do work.
> We've got some teams using CruiseControl here, and it is doing well.
> The reasons I think that gump registers so many failures are:
>
> 1) The environment in which gump runs is not identical to the
> environment the developers run (OS, jdk, jars, etc), and I'm
> not sure if it is even well defined.
> Now, given that these are supposed to be cross platform
> java projects, that shouldn't be an issue, but it has been,
> and will continue to be.
When has it been?
If an OS issue is found, Gump did its job.
The 'cross HEAD CVS', which is how i think of Gump, does something that
developers don't do, but should have done for them - which is early
detection of interface-ish problems.
There is nothing (other than the sloth of Daedalus) which prevents us
from adding any 'test' we want - Gump is running the Velocity testbed,
for example, which is more than interface-related, but functional as
well.
I once thought it important to setup Gump tests that specify a specific
version set (i.e. the release versions of all dependencies), but I
realize that's pointless. Do the test once, and repeating can add no
new information.
> Unless each developer replicates the Gump environment on his/her
> workstation, they will not find all problems. However doing so
> will only fix problems for that environment, so in some ways
> leaving it slightly undefined is helpful to keep portability.
Yes.
> 2) Developers can't/don't run the tests before checkin.
> In our situation, if you checkin something that breaks the tests,
> you're an idiot.
> I don't think that happens in apache, for a few reasons.
> The primary one being that most people are doing this in the spare
> time, and a channeling in patches from numerous sources. Forcing
> full rebuilds with unit tests would make that channel so small that
> work would grind to a virtual stand-still.
Not sure I buy this - Velocity has a unit test suite that has saved us
(me) in countless instances, so I know if a change has altered the gross
functional envelope that we have been able to define.
>
> 3) Developers can't/don't test other projects.
> This is particularly relevant to ant, but also to some of the XML
> and (soon) commons modules.
> A number of build failures have been due to changes in ant.
> Ant should continue to be free to change things as needed to make
> ant better, and that will continue to break projects that rely
> on specific ant features/bugs.
> Unless the developers are going to rebuild all the dependant
> projects everytime they make a change, then this will keep
> happening.
>
Interesting topic : like any other released package/project/tool with
users, does Ant ensure that it is backwards compatible with itself, at
least on major version boundaries?
(I think it should be...)
> [SNIP]
>
> 5) Attitude.
> Given the length of time that some projects remain broken, I guess
> some projects don't particularly care too much. Which is a pity.
> (Granted some projects believe they've fixed it, and that gump is
> misbehaving, so you can't blame them for that).
> I think if it gets repositioned to fill such a role (or maybe it
> already is, and I'm misinformed) then solving (4) will be useful.
> Ultimately though, (5) is the kicker.
That's a matter of resources for (4) and time and social engineering for
(5), I think. With an all volunteer group, I think it has to be worked
into the culture. While you could force the issue by making it a part
of being a Jakarta project, I don't think we want to do that.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
