commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [GUMP] how to point the finger?
Date Thu, 02 May 2002 16:51:19 GMT
Tim,

On Thu, 2 May 2002 14:09:22 +1000 , Tim Vernum <Tim.Vernum@macquarie.com> wrote:

> 
> From: Ovidiu Predescu [mailto:ovidiu@cup.hp.com]
> 
> > The tool works by keeping track of who modified the files since the
> > last build, and what were the changes in the number of regression
> > tests. If you modify a file lets say, that introduces a regression in
> > the automated tests, you will receive an email notification containing
> 
> > Would it be possible to have a similar setup for GUMP? 
> 
> In my mind it might not be the right way to go.
> 
> It could be helpful that if GUMP fails to build a module it also 
> generates a list of changes since the last successful build (so you
> can know what was done), but there are two issues.
> 
> 1] As Lakta has recently seen, the change might be inside a dependency.
> Do you list every change to Xerces/Ant/?? also?
> 
> 2] The project is owned by the community of developers.
> While each person should be responsible for making sure their changes
> don't break the build, it is the responsibility of all the developers
> to make sure the module is correct.
> That's why people get CVS commit mails.
> 
> It is easiest if the person who made the change goes in and fixes it,
> because they know what they've done, (hence having a list of changes
> will come in handy) but there is the risk that too much finger 
> pointing will reduce the community-ownership of the project.
> 
> Just an alternative viewpoint.

What I had in mind were not only build failures, but also small
behavior changes which have far effects in somebody else's code. While
working in GCC I've seen this too many times, and I see the same
pattern surfacing in the Apache Jakarta and XML projects.

A requirement for this kind of checks is to have good test suites put
in place.

With respect to how far you go listing the changes, I think that yes,
you should provide ways to go as deep as possible listing the
changes. Otherwise you don't have a way to catch important changes.

As an interesting example of such a change, take a look at GUMP
itself. Just try to use the latest version of Xalan instead of
2.2D13. The code compiles just fine, but as soon as you try executing
it, it will fail with a runtime error. A test in GUMP itself would
have probably caught this issue.

The problem with small behavior changes is that their implications are
not understood immediately. With a good test suites which exercise the
code things are much easier to handle. If GUMP would be able to take
advantage of the results of all the test suites, it would be really
great.

I don't think such finger pointing takes away any of the
community-ownership of the project. On the contrary, I think it helps
understand what are the connections between projects, as it makes you,
as a developer, understand the implication of the changes you make
much faster than having somebody else scratching their head looking
for the bug.

Regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message