commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] issues highlighted by analysis
Date Tue, 26 Apr 2005 18:59:27 GMT
On Mon, 2005-04-25 at 13:53 -0700, Brian Stansberry wrote:
> --- robert burrell donkin
> <robertburrelldonkin@blueyonder.co.uk> wrote:
> 
> > On Sun, 2005-04-24 at 16:43 -0700, Brian Stansberry
> > wrote:
> > > --- robert burrell donkin
> > > <robertburrelldonkin@blueyonder.co.uk> wrote:
> > 
> > <snip>
> > 
> > > > i'm wondering whether to commit them onto a
> > branch
> > > > so that everyone can
> > > > take a look, check their accuracy and take a
> > look at
> > > > fixes. opinions?
> > > 
> > > Please forgive if this is a stupid question, but
> > why
> > > on a branch?
> > 
> > to prevent a gump storm :)
> > 
> > gump builds from TRUNK. committing unit tests that
> > failure onto TRUNK
> > means that gump will fail to build JCL. last time
> > that happened, there
> > were literally hundreds of dependent products that
> > could not be built.
> > each failed project means an email every day until
> > it's fixed. thus, a
> > gump storm. 
> > 
> 
> Wow.  That's a shame.  I'd think not being able to add
> unit tests that fail to the main line would tend to
> lead to a lot fewer unit tests.

of course, they can be committed so long as they aren't run as part of
the main test target. unit tests that are intended to fail would require
some documentation and seems a bit strange for TRUNK.

given the general interest, i'll probably tidy up the test i have and
commit them into TRUNK (for now) but i won't call the target from the
main test target.

> BTW, a couple weeks back I added a unit test patch to
> the JBoss Memory Leak bug.  The added test will fail,
> so the patch shouldn't be committed to trunk. (Thus
> confirming my point above).

part of the required habit for a committer is to get in the right
habits. once the work's finished and ready for committing, always
update, build the distribution and run the standard unit tests. never
commit a patch with broken unit tests.

i'm coming round to simon's idea that an additional directory (a peer to
TRUNK and BRANCHES) may be the best solution. we could add memory issues
analysis next to the discovery stuff. 

- robert


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


Mime
View raw message