Philosophical discussions are always worth a couple of cents of my own :-)
On Wed, 23 May 2001, Tim Vernum wrote:
>
> From: Sam Ruby (23 May 2001 10:02 AM)
>
> > Jason van Zyl wrote:
> > >
> > > What is going on here? I fixed this code almost two days ago.
> >
> > http://jakarta.apache.org/builds/gump/2001-05-21/cvs_index.html
> > http://jakarta.apache.org/builds/gump/2001-05-22/cvs_index.html
> >
> > Compare this to the "good old days":
> >
> > http://jakarta.apache.org/builds/gump/2001-04-15/cvs_index.html
> >
> > Daedalus performance (or lack thereof) has basically gotten
> > to the point
> > where programs like Gump are great in theory, but impractical in
> > practice...
>
> (Disclaimer: I'm not a committer on any project, so my opinion is
> objective, but slightly under-informed, and without authority)
>
> 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.
> 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.
Most of the failure issues here are based on slow CVS updates, not on
environmental differences.
But the important point is a little more subtle - the "write once run
anywhere" Java mantra is not just a marketing slogan. We as Java
developers should be designing to minimize environmental
dependencies. GUMP focuses on one kind of dependency (cross project
dependency at compile time), which is important, but it's not the only one
(for example, code to build file paths that uses hardcoded '/' or '\'
delimiters). However, GUMP has served a valuable role in just raising
awareness of these issues, above and beyond it's usefulness as a tool.
>
> 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.
What does "in apache" mean? There is no one single project here -- each
Jakarta project (for example) consists of its own constellation of
developers. Sure, there is overlap, but nobody at all is involved in
everything.
> 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.
>
Part of the issue is a (good) increase in expectations. It used to be
that, if you didn't break the build on your own project, you were doing
good. (For amusement, check out the warnings about what to do before
checking code in on many of the project README files). Now, if we don't
run the appropriate unit test suites, other developers on the same project
start frowning at you. GUMP (along with attitudes like yours about "test
first before committing") are becoming much more widespread.
The other reality is that Moore's law tends to make the "full rebuilds"
issue moot. I just upgraded my home PC, and as a result I can build
Tomcat (modest-sized but still complex), from scratch, in less than 20
seconds. There is absolutely no excuse not to do that kind of thing on
your own project any more.
> 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.
>
Having to rebuild "foreign" projects is not something that I should really
have to worry about. Moreover, I don't know the code of that project well
enough to test it anyway. I want to just trust the developers of the
projects I depend on.
GUMP has raised awareness of the negative impacts that API changes have on
other projects (be careful what methods you make public, because people
will use them :-). Next step is to be more picky about functionality
changes that don't involve API changes a compiler will catch for you.
> 4) Gump (I think) only runs once a day.
> This means that there's up to 24hrs before you know that you broke
> something.
> CruiseControl (generally) runs every 15 minutes, and rebuilds if
> the project has had a new checkin. This way you know quite quickly
> that you broke something.
> Potentially, you could have gump work in a system where if a project
> fails a build, it moves to nightly builds only, but onces it passes
> a nightly build it moves to a build every 3(?) hours, until it fails
> again.
> That way, you're not going to keep getting "build failed" messages
> all days, waiting for someone to fix it, but you will know straight
> away (alomost) when a change breaks a project.
>
I run continuous tests on my own in house network stuff too. But doing
that across the Internet on a shared server would be decidedly unfriendly.
The other reality is that I'm not around to pay attention to build
failures for a large number of those hours anyway (gotta sleep sometime,
gotta work on the day job sometime, ...).
> 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.
If you look back into history, the number of projects whose developers act
this way has been decreasing steadily. That would never have happened
without GUMP, imho.
> (Granted some projects believe they've fixed it, and that gump is
> misbehaving, so you can't blame them for that).
>
That's an unfortunate reality at the moment.
>
> Anyway, the conclusion I can see is that for reasons 1-3, gump is
> actually replacing build/testing on developers machines, and is
> generally being the method by which people are alerted that they broke
> something, rather than them discovering it themselves.
> I don't think that this is a problem, but it will mean that gump is
> going to keep failing.
> 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.
>
> JM2C.
>
As a developer heavily involved since the beginnings of Jakarta in three
projects (Tomcat, Struts, and Commons) and dependent on 10-20 others, I
reach a different conclusion. At least partly because of GUMP (and Sam's
nagging, of course :-), consciousness has been substantially raised about
API stability across many of the projects I depend on. Releases are more
formal. Promises about stability are starting to be made (and
kept). And, at the same time, large numbers of projects are adding unit
tests that are being used every day by the developers to minimize
regressions introduced by changes.
All caused by GUMP? Nope, but it sure has helped.
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
