Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73819
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender)
Message-ID: <535D5E07.4060607@sugarcrm.com>
Date: Sun, 27 Apr 2014 12:44:07 -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: Derick Rethans <derick@php.net>, 
 PHP Internals <internals@lists.php.net>
References: <535A13E1.3050106@sugarcrm.com> <alpine.DEB.2.10.1404261028260.4404@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.10.1404261028260.4404@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] CI tests RFC
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> I have a comment (not specifically to you). We can't seriously be 
> suggesting that RMs can just revert commits. This is a really rude thing 
> to do in an open source project. We're doing this for fun, and people 
> immediately reverting your commits takes (more) fun out of it.

I agree. That's why we have time limits before that should happen.
However, it has happened that people made commits which break things and
then have gone unresponsive for an extended period of time, with broken
commits laying there and making everybody work much harder to ensure
breakage does not spread (if CI is red, then any pull against it is red,
so we can't really trust the pulls tests, and when we merge them we
don't know anymore what exactly broke it and it becomes a mess very
quickly). So I think the normal workflow would be as follows:

1. Make pull
2. See the pull test green
3. Merge the pull
4. Ensure the CI for main branch is still green
5. Go have a beer/coffee/well-deserved rest

However, if somebody commits something that breaks the CI, and is not
fixing it, we need to know it's OK to fix it, and we need the committer
to know too if he's negligent about CI hygiene his commit may not be
accepted.
If there's an exceptional situation - e.g. somebody breaks the CI but
knows how to fix it but can do it only in 3 days because of stuff, he
can always write to the list saying so and RM should make an exception.
What we're trying to prevent is committer not reacting and everybody
sitting around doing nothing and CI being red for weeks.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227