Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113860 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47412 invoked from network); 30 Mar 2021 09:54:38 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Mar 2021 09:54:38 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E7B0D180541 for ; Tue, 30 Mar 2021 02:51:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from xdebug.org (xdebug.org [82.113.146.227]) by php-smtp4.php.net (Postfix) with ESMTP for ; Tue, 30 Mar 2021 02:51:52 -0700 (PDT) Received: from [10.12.181.1] (unknown [85.255.236.234]) by xdebug.org (Postfix) with ESMTPSA id 2970310C035; Tue, 30 Mar 2021 10:51:51 +0100 (BST) Date: Tue, 30 Mar 2021 10:51:49 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <6c3d7c13-d7cd-c1cc-5876-2b8c200a017c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: internals@lists.php.net,Max Semenik ,Stanislav Malyshev CC: Internals Message-ID: Subject: Re: [PHP-DEV] Changes to Git commit workflow From: derick@php.net (Derick Rethans) On 30 March 2021 10:43:41 BST, Max Semenik wrot= e: >On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev > >wrote: > >> Hi! >> >> On 3/29/21 4:49 AM, Max Semenik wrote: >> > Would it also make sense if direct pushes (bypassing the pull >requests >> > system) were disallowed completely? I can see multiple problems >with >> direct >> > pushes: >> >> This is possible=2E In fact, there are Git bots that make it easier >(e=2Eg=2E >> prow: https://github=2Ecom/kubernetes/test-infra/tree/master/prow) - I >am >> using such system over Github at my $DAYJOB and it's generally >working >> well=2E It even has its own built-in karma-like system=2E However, it h= as >> some downsides, as the experience shows: >> >> 1=2E Quick management patches, typofixes, release management patches, >etc=2E >> become more high friction processes=2E >> 2=2E Setup and configuration of such system involves some time >investment >> by some knowledgeable people, and it has certain learning curve >(though >> once it is set up, it's pretty easy to use)=2E >> 3=2E Somebody knowledgeable needs to maintain it, as periodically bots >can >> get stuck and need a gentle kick to continue=2E >> 4=2E CI needs to be very stable and clean for having CI pass as gateway >to >> merge, otherwise a flaky test can block all work in the repo for >days=2E >> 5=2E Managing multiple active branches can be a pain=2E >> >> None of these are critical, and we could start small and build it >> incrementally, of course=2E >> > >We don't even have to use bots - GitHub allows you to require passing >CI >and/or approving reviews to merge=2E How well does that work for merging up fixes from an older bug fix branch = up through PHP 7=2E4, PHP 8=2E0, and then into master? Or for things like new timezone definitions, which is now automated, and w= ould then require a pointless PR?=20 It sounds like an annoying hurdle=2E cheers, Derick