Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113863 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 68766 invoked from network); 30 Mar 2021 12:32:05 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 30 Mar 2021 12:32:05 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 718521804D3 for ; Tue, 30 Mar 2021 05:29:21 -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-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (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:29:21 -0700 (PDT) Received: by mail-lj1-f176.google.com with SMTP id r20so19686953ljk.4 for ; Tue, 30 Mar 2021 05:29:21 -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=r6nkBCjyGbvFjsg0xmhCm/vsV6Zrwi9XVuYOFidEnY0=; b=idiaM7gBqahjjy0Kktz3IjU+nU+zU6YNwyWA2djnAb/CM3VF7jbpInl927RBnsjfIH Q7g5hGt/atgMotgHfhn//U7RhXe/QzJYL+eVVRVErdSOCHvJXaMtjc/oxk4qh9HnECs7 JgqaVHtrQaSa/8riBWcO5pjzLkPSvo/54xM3SH/x4fGIMDamGycSgBqDsWJnJ7Qh6M5C veRWuAhgtAeet9Qty9JaIgvbN6XBzaMLGgZTq+GIjy/be/MUPPgGKRrN5bRk7uog3exp QixybcjSVYs4xLmbJdZoft/FBxjwkSB89+Y8QFosO7ymA4gbV1xTx/XjwODvYwdcnBFU mdgQ== X-Gm-Message-State: AOAM531G95Uz+D7hjyuOLAxQiiX9GzeNnx3VELsoTiGpTA//AE2ve+zQ 5GYJyZ7filoJIWttNv9RvScLsxwXnhqgaU7gUAaxWnZT X-Google-Smtp-Source: ABdhPJyc2uEPcy20j5eIzHY6DJvH6o2z9v4uKFtqo6wFf8H2xWye27Jaokk7bUq7lHeS2sHG1z1L/fSVsBPMow9eF5c= X-Received: by 2002:a2e:9bcd:: with SMTP id w13mr20512600ljj.43.1617107358073; Tue, 30 Mar 2021 05:29:18 -0700 (PDT) MIME-Version: 1.0 References: <6c3d7c13-d7cd-c1cc-5876-2b8c200a017c@gmail.com> In-Reply-To: Date: Tue, 30 Mar 2021 13:29:07 +0100 Message-ID: To: Mike Schinkel Cc: Derick Rethans , PHP Internals Content-Type: multipart/alternative; boundary="000000000000a446cc05bec025fa" Subject: Re: [PHP-DEV] Changes to Git commit workflow From: bukka@php.net (Jakub Zelenka) --000000000000a446cc05bec025fa Content-Type: text/plain; charset="UTF-8" On Tue, Mar 30, 2021 at 1:21 PM Jakub Zelenka wrote: > > > 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. > > Actually if we needed to do cherry-pick that conflicts, we would still need PR's for lower branches like having multiple PR's for the same thing that requires conflicting implementation (cannot be cherry-picked by bot). Think having everything going through the PR's has certainly benefit as we could require reviews for each PR which would be certainly good for security. A similar worklfow is done in OpenSSL for example except it's a bit different flow there because there are not too many fixes and changes in lower branches. Cheers Jakub --000000000000a446cc05bec025fa--