Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73828
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Mon, 28 Apr 2014 11:05:05 +0100 (BST)
To: Stas Malyshev <smalyshev@sugarcrm.com>
cc: PHP Internals <internals@lists.php.net>
In-Reply-To: <535D5E07.4060607@sugarcrm.com>
Message-ID: <alpine.DEB.2.10.1404281057350.4404@whisky.home.derickrethans.nl>
References: <535A13E1.3050106@sugarcrm.com> <alpine.DEB.2.10.1404261028260.4404@whisky.home.derickrethans.nl> <535D5E07.4060607@sugarcrm.com>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] [VOTE] CI tests RFC
From: derick@php.net (Derick Rethans)

On Sun, 27 Apr 2014, Stas Malyshev wrote:

> 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

Maybe, but for this to work you need to teach everybody proper git 
workflows. In a project with many infrequent committers, you're never 
going to get this done. Heck, it can be hard in a 3 man team to have 
proper git discipline.

> 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.

Then why do you have as an option in your voting "Revert immediately"? 
That should never be happening.

cheers,
Derick