You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2005/10/26 17:43:57 UTC
Re: When to commit failing tests (was: Re: svn commit: r17032 - trunk/subversion/tests/clients/cmdline)
"Peter N. Lundblad" <pe...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to commit failing tests (was: Re: svn commit: r17032 - trunk/subversion/tests/clients/cmdline)
Posted by Erik Huelsmann <eh...@gmail.com>.
[ snip about creating issues for XFAIL tests ]
> 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.
ok, ok, if that's how we work, I'll comply...
bye,
Erik.
Re: When to commit failing tests (was: Re: svn commit: r17032 - trunk/subversion/tests/clients/cmdline)
Posted by Ivan Zhakov <ch...@gmail.com>.
On 26 Oct 2005 12:43:57 -0500, kfogel@collab.net <kf...@collab.net> wrote:
> "Peter N. Lundblad" <pe...@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
Re: When to commit failing tests (was: Re: svn commit: r17032 -
trunk/subversion/tests/clients/cmdline)
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 26 Oct 2005, Justin Erenkrantz wrote:
> --On October 26, 2005 12:43:57 PM -0500 kfogel@collab.net wrote:
>
> > the person can just set the test XFail, and file an issue or do
>
> I don't have as strong a problem with setting it to XFail (could we add a
> new code such as KnownFailure?), but not committing the test to the tree
> because there's no fix is my concern. -- justin
>
Then it seems like we are in agreement. My original complaint (or rather
commit) was to make a failing test XFail. I'm *for* XFail tests.
regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to commit failing tests (was: Re: svn commit: r17032 - trunk/subversion/tests/clients/cmdline)
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> I don't have as strong a problem with setting it to XFail (could we
> add a new code such as KnownFailure?), but not committing the test to
> the tree because there's no fix is my concern. -- justin
This discussion is about committing a failing test not as XFail; as
far as I know there is no other controversy here...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to commit failing tests (was: Re: svn commit: r17032 -
trunk/subversion/tests/clients/cmdline)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On October 26, 2005 12:43:57 PM -0500 kfogel@collab.net wrote:
> the person can just set the test XFail, and file an issue or do
I don't have as strong a problem with setting it to XFail (could we add a
new code such as KnownFailure?), but not committing the test to the tree
because there's no fix is my concern. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org