You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kamesh Jayachandran <ka...@collab.net> on 2007/08/09 13:28:09 UTC
Re: svn commit: r25991 - in trunk/subversion/tests/cmdline: . svntest
epg@tigris.org wrote:
> Author: epg
> Date: Wed Aug 8 11:10:32 2007
> New Revision: 25991
>
> Log:
> ra-dav (neon) hasn't shown error output from pre-revprop-change since
> before 1.4.0, and has since r22712 always claimed a revprop change
> succeeds, giving no indication at all that the hook denied it.
>
> * subversion/tests/cmdline/prop_tests.py
> (revprop_change): Test that we get an error upon trying to set a
> revprop when pre-revprop-change is *not* enabled, or enabled but
> returning an error.
>
Eric,
Shouldn't you put this test as XFail if you want to test the
un-implemented feature(*Not propagating the pre-revprop-change hook
failure*).
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25991 - in trunk/subversion/tests/cmdline: . svntest
Posted by Erik Huelsmann <eh...@gmail.com>.
On 8/9/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> "Erik Huelsmann" <eh...@gmail.com> writes:
>
> > Yes. But you already pointed that out in that e-mail. What use is
> > buildbot to others if this *known* regression makes all ra_neon builds
> > fail? I'm strongly against committing failing tests knowingly, for
>
> What? Why does it make builds fail? It should only result in
I'm sorry I meant "make ra_neon builds fail the tests". The PASS vs
FAIL subject headers trigger (at least for me) whether I should look
in a test result mail. If they all say FAIL, that doesn't work
anymore.
> this one test showing up as failing in automated test runs.
> Which is as it should be, no? We don't want all lights green if
> the code is known broken!
>
> But, that's just me :). I don't object to turning this into an
> XFail instead.
>
> > I don't think a failing test is the only (or even right) way to find a
> > developer to get the regression fixed. If you think a regression is to
> > be fixed before the next release, you can file a P1 or P2 issue
> > against the next release...
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=2861
Thanks.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25991 - in trunk/subversion/tests/cmdline: . svntest
Posted by Lieven Govaerts <sv...@mobsol.be>.
Eric Gillespie wrote:
> "Erik Huelsmann" <eh...@gmail.com> writes:
>
>
>> Yes. But you already pointed that out in that e-mail. What use is
>> buildbot to others if this *known* regression makes all ra_neon builds
>> fail? I'm strongly against committing failing tests knowingly, for
>>
>
> What? Why does it make builds fail? It should only result in
> this one test showing up as failing in automated test runs.
> Which is as it should be, no? We don't want all lights green if
> the code is known broken!
>
The best way to handle a FAILing test is to detect it asap and then fix
it asap.
If fixing the failed test isn't an option, we have to choose between:
- reverting the change that causes the test to fail
- marking the test as XFail and reporting an issue with milestone 1.5
(since it's a regression, we want to have it fixed before releasing)
- keeping the FAILed test. Here buildbot will start to get useless.
What's the use of being reminded of a failing test 5 times a day, it
only makes you ignore those emails/RSS feeds.
To keep buildbot useful for the project, the tests should pass most of
the time, and if they're failing that should be a temporary situation.
The longer it takes to bring buildbot lights back to green the bigger
the risk more failing tests show up which are getting ignored in the
flood of emails. We have other and better ways to indicate the
Subversion code is known broken (in certain places), use Issues and
XFailing tests for that.
Lieven
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25991 - in trunk/subversion/tests/cmdline: . svntest
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Erik Huelsmann" <eh...@gmail.com> writes:
> Yes. But you already pointed that out in that e-mail. What use is
> buildbot to others if this *known* regression makes all ra_neon builds
> fail? I'm strongly against committing failing tests knowingly, for
What? Why does it make builds fail? It should only result in
this one test showing up as failing in automated test runs.
Which is as it should be, no? We don't want all lights green if
the code is known broken!
But, that's just me :). I don't object to turning this into an
XFail instead.
> I don't think a failing test is the only (or even right) way to find a
> developer to get the regression fixed. If you think a regression is to
> be fixed before the next release, you can file a P1 or P2 issue
> against the next release...
http://subversion.tigris.org/issues/show_bug.cgi?id=2861
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25991 - in trunk/subversion/tests/cmdline: . svntest
Posted by Erik Huelsmann <eh...@gmail.com>.
On 8/9/07, Eric Gillespie <ep...@pretzelnet.org> wrote:
> Kamesh Jayachandran <ka...@collab.net> writes:
>
> > Shouldn't you put this test as XFail if you want to test the
> > un-implemented feature(*Not propagating the pre-revprop-change hook
> > failure*).
>
> No, it's not an unimplemented feature, but a regression. See
> http://svn.haxx.se/dev/archive-2007-08/0010.shtml
Yes. But you already pointed that out in that e-mail. What use is
buildbot to others if this *known* regression makes all ra_neon builds
fail? I'm strongly against committing failing tests knowingly, for
regressions or otherwise. Lieven has been reviewing all XFail tests
for every release and comparing them with previous releases, so
regressions don't go undetected.
I don't think a failing test is the only (or even right) way to find a
developer to get the regression fixed. If you think a regression is to
be fixed before the next release, you can file a P1 or P2 issue
against the next release...
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r25991 - in trunk/subversion/tests/cmdline: . svntest
Posted by Eric Gillespie <ep...@pretzelnet.org>.
Kamesh Jayachandran <ka...@collab.net> writes:
> Shouldn't you put this test as XFail if you want to test the
> un-implemented feature(*Not propagating the pre-revprop-change hook
> failure*).
No, it's not an unimplemented feature, but a regression. See
http://svn.haxx.se/dev/archive-2007-08/0010.shtml
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org