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
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/
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
On Wed, May 7, 2014 at 9:26 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
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--
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
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/
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