FAQ
Hi!

By the vote of 16 to none the RFC https://wiki.php.net/rfc/travis_ci is
accepted. I will enable sending notifications of failures to the list
and add changes to README.RELEASE_NOTES shortly.

For the ways to deal with the failures the most accepted ways would be
to revert broken commits unless fixed in following 2 days, or to update
the tests. XFAIL is marginally not passing the bar, and longer revert
time seems not to be popular.
Please note however that these are the general guidelines for the
exceptional case where the patch author does not handle the problem by
himself. Which should normally always happen. So please be responsible
and use the github pulls which automatically test the submitted code.

Thanks,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Search Discussions

  • Andrea Faulds at May 7, 2014 at 6:53 pm

    On 7 May 2014, at 19:00, Stas Malyshev wrote:

    For the ways to deal with the failures the most accepted ways would be
    to revert broken commits unless fixed in following 2 days, or to update
    the tests.
    So, to clarify, does this mean that, in future, we’ll be changing tests to accept bugs if trunk contains the bug?

    --
    Andrea Faulds
    http://ajf.me/
  • Stas Malyshev at May 7, 2014 at 7:26 pm
    Hi!
    So, to clarify, does this mean that, in future, we’ll be changing tests
    to accept bugs if trunk contains the bug?
    This means that changing test is one of the acceptable solutions to fix
    CI failure. Of course, if it is a bug, then it makes no sense to change
    the test, in that case the change has to be reverted.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Ferenc Kovacs at May 7, 2014 at 8:31 pm

    On Wed, May 7, 2014 at 9:26 PM, Stas Malyshev wrote:

    Hi!
    So, to clarify, does this mean that, in future, we’ll be changing tests
    to accept bugs if trunk contains the bug?
    This means that changing test is one of the acceptable solutions to fix
    CI failure. Of course, if it is a bug, then it makes no sense to change
    the test, in that case the change has to be reverted.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    This is why I didn't liked that option, as that option only makes sense,
    when doing it is plain wrong.
    If somebody fixed a bug, which broke a test, but the change is intentional
    or unaviodable then fixing the test is the right thing to do, and doesn't
    really requires any rfc to support.
    If somebody changed something, which broke some test unintentionally or
    without proper justification then updating the test to accomodate the new
    behavior without ringing the alarm bell is a bad thing to do imo.
    But of course they are only options, so I guess people/RMs won't really use
    it to shot themselfs to the leg.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Andrea Faulds at May 7, 2014 at 8:35 pm

    On 7 May 2014, at 21:31, Ferenc Kovacs wrote:
    This is why I didn't liked that option, as that option only makes sense,
    when doing it is plain wrong.
    If somebody fixed a bug, which broke a test, but the change is intentional
    or unaviodable then fixing the test is the right thing to do, and doesn't
    really requires any rfc to support.
    If somebody changed something, which broke some test unintentionally or
    without proper justification then updating the test to accomodate the new
    behavior without ringing the alarm bell is a bad thing to do imo.
    But of course they are only options, so I guess people/RMs won't really use
    it to shot themselfs to the leg.

    Hopefully. The process, wherever it’s documented, must make it clear that the test should only be changed if this is the new expected behaviour, however.

    --
    Andrea Faulds
    http://ajf.me/
  • Stas Malyshev at May 7, 2014 at 9:22 pm
    Hi!
    If somebody fixed a bug, which broke a test, but the change is
    intentional or unaviodable then fixing the test is the right thing to
    do, and doesn't really requires any rfc to support.
    It does not "require" RFC, the RFC just records what we agreed upon. If
    it's obvious, fine, even better :)
    If somebody changed something, which broke some test unintentionally or
    without proper justification then updating the test to accomodate the
    new behavior without ringing the alarm bell is a bad thing to do imo.
    I agree. The RFC is not meant to create some way to do bad things. You
    still need to apply common sense and consensus understanding, the RFC is
    just captures what we think about it so that everybody knows that's what
    we're doing.
    But of course they are only options, so I guess people/RMs won't really
    use it to shot themselfs to the leg.
    Yes, I think current RMs understand how it should work, and I am
    confident we can keep selecting people to be RMs that understand it.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 7, '14 at 6:00p
activeMay 7, '14 at 9:22p
posts6
users3
websitephp.net

People

Translate

site design / logo © 2022 Grokbase