Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113864
Message-ID: <D12AAFF7-B16E-4535-86D2-0FC6D957CDBA@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_598D8391-FC1B-41A3-9554-6E1F82FC18CA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 30 Mar 2021 09:34:45 -0400
In-Reply-To: <CAEKnhAENADeVQTyWASi-i7eoXa7iZ6Uo-bo+omNDgF3Wnb8TLQ@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: Jakub Zelenka <bukka@php.net>
References: <CAF+90c9A6zG-nYzc3NNtWGjN7y5FmwqnYzjq6GSFC5NtRsOT0w@mail.gmail.com>
 <CAGgaK7JywM+aU4YTK3tUr3xjN5746LDoda4SC_=A+msGdWhNyg@mail.gmail.com>
 <6c3d7c13-d7cd-c1cc-5876-2b8c200a017c@gmail.com>
 <CAGgaK7JxmLexnkrt+kLfV47wi=KoeqhnzGjTyrcAQtxemKoSKQ@mail.gmail.com>
 <E344AED6-17BA-4FC9-9173-17F524C40766@php.net>
 <A7687BC9-9457-4E54-93CC-289F95F30EF6@newclarity.net>
 <CAEKnhAGgrX9467Rku98cLyC9CM+cwGwWd3dtaQvS_jjebH1dmA@mail.gmail.com>
 <CAEKnhAENADeVQTyWASi-i7eoXa7iZ6Uo-bo+omNDgF3Wnb8TLQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Changes to Git commit workflow
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_598D8391-FC1B-41A3-9554-6E1F82FC18CA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Mar 30, 2021, at 8:29 AM, Jakub Zelenka <bukka@php.net> wrote:
>=20
>=20
>=20
> On Tue, Mar 30, 2021 at 1:21 PM Jakub Zelenka <bukka@php.net =
<mailto:bukka@php.net>> wrote:
>=20
>=20
> On Tue, Mar 30, 2021 at 12:47 PM Mike Schinkel <mike@newclarity.net =
<mailto:mike@newclarity.net>> wrote:
>=20
>=20
> > On Mar 30, 2021, at 5:51 AM, Derick Rethans <derick@php.net =
<mailto:derick@php.net>> wrote:
> >=20
> > On 30 March 2021 10:43:41 BST, Max Semenik <maxsem.wiki@gmail.com =
<mailto:maxsem.wiki@gmail.com>> wrote:
> >> On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev
> >> <smalyshev@gmail.com <mailto:smalyshev@gmail.com>>
> >> wrote:
> >>=20
> >>> Hi!
> >>>=20
> >>> 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:
> >>>=20
> >>> 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 =
<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:
> >>>=20
> >>> 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.
> >>>=20
> >>> None of these are critical, and we could start small and build it
> >>> incrementally, of course.
> >>>=20
> >>=20
> >> We don't even have to use bots - GitHub allows you to require =
passing
> >> CI
> >> and/or approving reviews to merge.
> >=20
> > 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?
> >=20
> > Or for things like new timezone definitions, which is now automated, =
and would then require a pointless PR?=20
>=20
> Accepting some PRs can be automated.  Repos can be protects on Github =
via per-branch rules[1] where permissions and requirements can be =
assigned.
>=20
> 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.
>=20
>=20
> 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.
>=20
>=20
> 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).
>=20
> 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.
>=20

When you speak of NEWS, do you mean this?

https://github.com/php/web-news <https://github.com/php/web-news>

If yes, then no problem.  Not only can different branches have different =
rules, different repos definitely can.  So worse case NEWS could be =
manual, but php-src could require PRs, if that is the best that could be =
done initially.

And as for special manual cases, I would be surprised is there wouldn't =
be a way that is not terribly hard to deal with special cases. After =
all, those working in GitOps are often dealing with enterprise use-cases =
and lots of legacy code and tons of special cases.=20

So it is really more of a divide-and-conquer approach; automate what can =
be and manually handle what cannot be automated. At least until you are =
able to upgrade the workflow, if ever.

-Mike

P.S. If nobody else has sufficient expertise here, maybe this would be a =
way I could finally start contributing something tangible to PHP since I =
have yet to learn how to add to or update the source code in C for PHP?=

--Apple-Mail=_598D8391-FC1B-41A3-9554-6E1F82FC18CA--