On Mon, 2005-04-25 at 13:53 -0700, Brian Stansberry wrote: > --- robert burrell donkin > <[EMAIL PROTECTED]> wrote: > > > On Sun, 2005-04-24 at 16:43 -0700, Brian Stansberry > > wrote: > > > --- robert burrell donkin > > > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
