I like what Paul said here. I was thinking the same about "unmaintained" contribs.
Otis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simpy -- http://www.simpy.com/ - Tag - Search - Share ----- Original Message ---- From: Paul Elschot <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Thursday, May 17, 2007 3:51:14 AM Subject: Re: Tests, Contribs, and Releases On Thursday 17 May 2007 09:10, Chris Hostetter wrote: ... > It could be argued that contribs are not important enough for contrib test > failures to result in a nightly build failing (I have no strong opinion > about this). It could also be argued that while it's good to run test > against the "core" on a regular basis (ie: in the nightly), test failures > should not in and of themselves block a release -- so the ReleaseTodo > doesn't need to include any mention of running tests (I would argue > against this position very strongly) > I'd rather have a few tests too many, which means that I would prefer to have the contribs tested by default, and at least before a new release. Contribs depend on the core, and their tests might also indicate a problem in the core, even though that is not their intention. When a contrib fails and is not fixed, that might be a good reason to remove it from the distribution. With such a policy the present contribs would also stay up to date, provided their tests are good enough. Thinking about it a bit more, there is a process to add contribs, but there is not really a process to remove them. The policy of removing a contrib before a release when its unit tests fail could make a nice fit for that. Regards, Paul Elschot --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
