[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: When to commit failing tests (was: Re: svn commit: r17032 - trunk/subversion/tests/clients/cmdline)

From: Ivan Zhakov <chemodax_at_gmail.com>
Date: 2005-10-26 22:12:59 CEST

On 26 Oct 2005 12:43:57 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
> > You normally don't commit something that you know have failing tests. If
> > the nightly build fail, because you did something platform-dependent or
> > something, then that's another story. I really don't think knowingly
> > commit failing tests non-XFail is a good way of alerting people that there
> > is a regression. You can post to dev@, file an issue or just fix it in a
> > few days.
> >
> > The problem with your approach is that it slows down things for everyone
> > else. When I want to run tests and get a failure, I have to examine and
> > dscover that it was just that other regression that still fails. If I made
> > a commit, I have to examine the nightly failure mails, because I can't
> > just assume that it is your test that fail. I think that's a waste of
> > time.
>
> +1 IMHO.
>
> The value of the test suite and the nightly builds is in notifying us
> of things we don't already know. So if someone knows that a test is
> failing, then we don't need to get that information by other means --
> the person can just set the test XFail, and file an issue or do
> whatever is appropriate, to record the fact of the failure.
I am +1 on Peter's point of view. Also we can add rule that any XFail
test should have issue. And keep issue number written near XFail test?
It prevent forget bugs.

--
Ivan Zhakov
Received on Wed Oct 26 22:14:21 2005

This is an archived mail posted to the Subversion Dev mailing list.