Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73612 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46108 invoked from network); 6 Apr 2014 03:25:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Apr 2014 03:25:10 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.99 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.99 smtp99.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.99] ([108.166.43.99:45726] helo=smtp99.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 16/31-39592-519C0435 for ; Sat, 05 Apr 2014 22:25:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 421A11B0788; Sat, 5 Apr 2014 23:25:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id E7B2D1B079F; Sat, 5 Apr 2014 23:25:05 -0400 (EDT) Message-ID: <5340C911.9040602@sugarcrm.com> Date: Sat, 05 Apr 2014 20:25:05 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pierre Joye CC: PHP Internals References: <53404E5E.6010109@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Travis CI unit tests From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I am not a big fan of changing tests to make it work, especially for > stable branches. Except for warning&co additions, a test change means I agree. But too often we face a situation where maintainer of the code is too busy or doesn't care enough to clean up the tests. Also, tests may be broken because of some deep bug that may take a lot of time to fix. So we need to develop a policy here. The policy may also be "don't care - broken tests means revert", if the community agrees with it. There is also the question of some tests working in one envt and not in another (intl tests are especially famous for it due to ICU changing their formats constantly) but I guess once we have a policy we can make tweaks and exceptions case-by-case. > One thing I would like to consider is peer reviews for patches in > stable branches. What you proposed goes in this direction, always go > through PR and travis before a change can be applied. That's one of the purposes. If I look on the patch, I want to see nice green checkmark, but that is impossible if our own build is always broken. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227