Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73829
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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>
	<alpine.DEB.2.10.1404281057350.4404@whisky.home.derickrethans.nl>
Date: Mon, 28 Apr 2014 12:15:54 +0200
Message-ID: <CAEZPtU7VVr_y28yyHzAujWR5Fu+oBv8S4KLprSwYy2cHHeBsmA@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] CI tests RFC
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Apr 28, 2014 at 12:05 PM, Derick Rethans <derick@php.net> wrote:
> 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.

I would rather say "rarelly happen". We have seen many last minute
commits (right before RC/beta and less frequently now stable f.e.), so
yes, it should be possible. Thanks the RFC process, it is not possible
anymore to have last minute large addition like we used to have.

But that brings me back to one of my replies. To avoid an endless
commit war, we should use a restricted set of stable branches. Only
the RMs can merge/commit to the ones used for the releases. Other
developers commit to the development branches (for stable, php-next or
master), while the RMs cherry pick what we need. Doing so reduce the
issues for developers while slightly increasing the work for RMs. The
latter is not too bad as it forces them to actually do some review
before merging.


-- 
Pierre

@pierrejoye | http://www.libgd.org