[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [logging] issues highlighted by analysis
From:       Brian Stansberry <bes_commons_dev () yahoo ! com>
Date:       2005-04-29 6:34:43
Message-ID: 20050429063443.1028.qmail () web31701 ! mail ! mud ! yahoo ! com
[Download RAW message or body]


--- robert burrell donkin
<robertburrelldonkin@blueyonder.co.uk> wrote:
> 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.
> 

Thought about this more and now tend to agree that
tests that fail are strange in TRUNK.  The purpose of
a unit test that fails is to document a problem even
if no solution is apparent.  But that's what a good
bug tracking system is for; a good place to put tests
that fail is as an attachment to a bug report.  Once
the problem is fixed, then the test can be moved into
the codeline.

> 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).

Or not ;)

> 
> 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.
> 

+1

> 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. 
>

+1.  BTW, My comment above re attaching to bug reports
wasn't in reference to the new tests you've written.

Brian

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


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

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

[prev in list] [next in list] [prev in thread] [next in thread]