Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113862 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 66533 invoked from network); 30 Mar 2021 12:24:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Mar 2021 12:24:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8F38C1804DD for ; Tue, 30 Mar 2021 05:21:20 -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.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 30 Mar 2021 05:21:17 -0700 (PDT) Received: by mail-lj1-f173.google.com with SMTP id u20so19582454lja.13 for ; Tue, 30 Mar 2021 05:21:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9xc2R+DdWaA+7q5ZfRxc1j9AuC71YkBLS9kiCEtv6Qw=; b=L5fnEL/7bkNPYAqJAKRpt1SFPffaW/EH8nmxb2wTR4OcGHpn+1O39g7FBD5jglvrfi fwe1vOmDsiKXA+MthPEv+kmqyefNfgfNTOdKLJNdEOkR1DDRk8WEcLyLdM2HbcvEDWBb obSP6WSu/AojAy5R/jiKdcKoIUZj4LwX7LLA0JkqNV9a7DlQ9YBAblsb4AWNvHKKSLMV 5SDZ/UF7cXi+wn1Sp3THtrhWaytUG+4F7bE8skkUk2SwRRIpuw7rNXJnJdDXZldWErm9 QBb/aGakbxtairTWdL6xHy2OJL+a6J3qVlRf05HcuI2u7MHi1G1JZ1dK6JsT8e0Ibcnx /6nA== X-Gm-Message-State: AOAM530OY7Bp48JHPZdl19y8JuwDbYVx8nbSEErt+XEX2CDrY5XEmCG2 qkln8pD3WDYcRSLKfq57hrwxNeAWOAJxCA+AQGM= X-Google-Smtp-Source: ABdhPJwj8Q997dAjjrKTrI3wJhAXoZ/sbRB6knLA1Uzu3uMeqW83o3ShX3GkvwNDOlmSJU9c02aCOICbX9YD/BPuGqY= X-Received: by 2002:a2e:885a:: with SMTP id z26mr20967539ljj.316.1617106875403; Tue, 30 Mar 2021 05:21:15 -0700 (PDT) MIME-Version: 1.0 References: <6c3d7c13-d7cd-c1cc-5876-2b8c200a017c@gmail.com> In-Reply-To: Date: Tue, 30 Mar 2021 13:21:04 +0100 Message-ID: To: Mike Schinkel Cc: Derick Rethans , PHP Internals Content-Type: multipart/alternative; boundary="000000000000df51cb05bec00840" Subject: Re: [PHP-DEV] Changes to Git commit workflow From: bukka@php.net (Jakub Zelenka) --000000000000df51cb05bec00840 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 30, 2021 at 12:47 PM Mike Schinkel wrote: > > > > On Mar 30, 2021, at 5:51 AM, Derick Rethans wrote: > > > > On 30 March 2021 10:43:41 BST, Max Semenik > wrote: > >> 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. In fact, there are Git bots that make it easier > >> (e.g. > >>> prow: https://github.com/kubernetes/test-infra/tree/master/prow) - I > >> am > >>> using such system over Github at my $DAYJOB and it's generally > >> working > >>> well. It even has its own built-in karma-like system. However, it has > >>> some downsides, as the experience shows: > >>> > >>> 1. Quick management patches, typofixes, release management patches, > >> etc. > >>> become more high friction processes. > >>> 2. 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). > >>> 3. Somebody knowledgeable needs to maintain it, as periodically bots > >> can > >>> get stuck and need a gentle kick to continue. > >>> 4. 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. > >>> 5. Managing multiple active branches can be a pain. > >>> > >>> None of these are critical, and we could start small and build it > >>> incrementally, of course. > >>> > >> > >> We don't even have to use bots - GitHub allows you to require passing > >> CI > >> and/or approving reviews to merge. > > > > How well does that work for merging up fixes from an older bug fix > branch up through PHP 7.4, PHP 8.0, and then into master? > > > > Or for things like new timezone definitions, which is now automated, and > would then require a pointless PR? > > Accepting some PRs can be automated. Repos can be protects on Github via > per-branch rules[1] where permissions and requirements can be assigned. > > PRs are actually a foundational component of GitOps[2] which is an > emerging best practice for managing infrastructure. It was initially for > Kubernetes deployments but has become recognized as being beneficial[3] for > automating software CI/CD[4] and other workflows. > > The problem is that this is not gonna easily work with the current PHP workflow and merging changes up. For example currently if you merge PR to PHP-7.4 and then you merge PHP-7.4 to PHP-8.0, you get most of the time conflict in NEWS that needs to be manually resolved. We would have to make the bot that is able to resolve those conflicts or come up with a different way how to handle NEWS. However sometimes there are code conflicts as well which the bot cannot resolve. I think the only solution would be to stop merging the branches up, do PR's always against master and then just cherry-pick the commit to lower branches (it could be potentially done by bot automatically in some / most cases) but again that would require some changes in the NEWS handling and possibly other things. Cheers Jakub --000000000000df51cb05bec00840--