Re: [PHP-DEV] [VOTE] noreturn type

[Peter Stalman]

Aw, my `terminus` suggestion didn't make it. ☹️

Thanks,
Peter

Re: [PHP-DEV] [VOTE] noreturn type

[Matthew Brown]

On Tue, 30 Mar 2021 at 12:55, Theodore Brown  wrote:

> On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown 
> wrote:
>
> > Hey everyone!
> >
> > The vote for adding noreturn is now open:
> >
> > https://wiki.php.net/rfc/noreturn_type
> >
> > Voting will run through April 13th
>
> Hi Matt and Ondrej,
>
> Thanks for your work on this RFC. I voted for `never` as the type name
> because it's more amenable to future use cases like compile-time
> exhaustiveness checks (example:
>
> https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type
> ).
>
> As a bonus `never` is more concise, avoids mashing two words together,
> and aligns with TypeScript, which I and many other PHP devs also use.
>
> Kind regards,
> Theodore


Awesome! The conciseness argument for "never" is already mentioned in the
RFC, as is TypeScript's use of the term.

Full disclosure (because neither of us is eligible to vote):
I slightly prefer "noreturn", and Ondrej strongly prefers "never".

Re: [PHP-DEV] [RFC] noreturn type

[Ilija Tovilo]

Hi Matthew

> I like the proposal. I also support the covariance.
>
> One question though.
> The RFC mentions possible future use of "nothing" as a bottom type for
> parameters in generics. This makes a lot of sense to me. Even without
> generics, it could be used for parameters in abstract methods.
>
> So why not already introduce "nothing" as the universal bottom type, and
> use it instead of "noreturn"?
> Can "noreturn" do anything that "nothing" can't?

I'm also a little confused by this statement. The exact wording from the RFC is:

> Arguments for never: ... It's a full-fledged type, rather than a keyword used 
> in a specific situation. A far-in-the-future generics proposal could use 
> never as a placeholder inside contravariant generic types.

>From what I understand, in Hack noreturn and never are both
full-fledged types. Nothing is a bottom type while noreturn is not.
Since in your proposal noreturn would also be a bottom type there's no
reason why it couldn't be used in covariant or contravariant generic
parameters.

Please correct me if I'm missing something.

Ilija

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] noreturn type

[Theodore Brown]

On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown  wrote:

> Hey everyone!
> 
> The vote for adding noreturn is now open:
> 
> https://wiki.php.net/rfc/noreturn_type
> 
> Voting will run through April 13th

Hi Matt and Ondrej,

Thanks for your work on this RFC. I voted for `never` as the type name
because it's more amenable to future use cases like compile-time
exhaustiveness checks (example:
https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type).

As a bonus `never` is more concise, avoids mashing two words together,
and aligns with TypeScript, which I and many other PHP devs also use.

Kind regards,
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Changes to Git commit workflow

[Sara Golemon]

On Tue, Mar 30, 2021 at 10:13 AM Christoph M. Becker 
wrote:

> > https://github.com/php/php-src/blob/master/NEWS which is a guaranteed
> merge
> > conflict between branches.
>
> Nope, see . :)
>
>
GAME. CHANGED.
This message constitutes your EFT (Entirely Fungible Token) for a beer if I
even meet you in person.

-Sara

Re: [PHP-DEV] [RFC] noreturn type

[Andreas Hennings]

Hello,

I like the proposal. I also support the covariance.

One question though.
The RFC mentions possible future use of "nothing" as a bottom type for
parameters in generics. This makes a lot of sense to me. Even without
generics, it could be used for parameters in abstract methods.

So why not already introduce "nothing" as the universal bottom type, and
use it instead of "noreturn"?
Can "noreturn" do anything that "nothing" can't?

-- Andreas

On Tue, 30 Mar 2021 at 07:18, Matthew Brown 
wrote:

> > On Mar 29, 2021, at 1:25 PM, Ilija Tovilo 
> wrote:
> >
> > Hi Matthew
> >
> >> Ondřej Mirtes and I present an RFC for the noreturn type:
> >> https://wiki.php.net/rfc/noreturn_type
> >>
> >> The feature already exists in Hack (the primary inspiration) and is
> >> currently supported by our static analysis tools inside docblocks, and
> we
> >> feel there's a good argument for it to be supported by PHP itself.
> >
> > Thanks for the RFC! I'm very much in support of it.
> >
> > Two small things:
> >
> > 1. Some magic methods like __toString currently require a specific
> > return type (like string in that case). Since noreturn is a bottom
> > type technically it should be possible to type hint those magic
> > methods with noreturn. It's not a big issue if that's not possible,
> > but it should be mentioned in the RFC.
> >
> > 2. noreturn is one of the few return types that would technically make
> > sense for __construct (other than void).
> >
> > class Foo {
> >public function __construct(): noreturn {
> >throw new Exception();
> >}
> > }
> >
> > new Foo();
> > bar(); // < Dead code
> >
> > Not sure this is worth supporting but I just wanted to mention it.
> >
> > Ilija
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
>
> Thanks, I’ll update the RFC to mention __toString, but I’ll steer clear of
> __construct
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Changes to Git commit workflow

[Christoph M. Becker]

On 30.03.2021 at 15:50, Sara Golemon wrote:

> On Tue, Mar 30, 2021 at 8:34 AM Mike Schinkel  wrote:
>
>> When you speak of NEWS, do you mean this?
>> https://github.com/php/web-news 
>>
> Negative. NEWS in all caps invariably refers to
> https://github.com/php/php-src/blob/master/NEWS which is a guaranteed merge
> conflict between branches.

Nope, see . :)

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [VOTE] noreturn type

[Matthew Brown]

Hey everyone!

The vote for adding noreturn is now open:

https://wiki.php.net/rfc/noreturn_type

Voting will run through April 13th

Best wishes,

Matt and Ondrej

Re: [PHP-DEV] Changes to Git commit workflow

[Sara Golemon]

On Tue, Mar 30, 2021 at 9:08 AM Mike Schinkel  wrote:

> On Mar 30, 2021, at 9:50 AM, Sara Golemon  wrote:
>
> On Tue, Mar 30, 2021 at 8:34 AM Mike Schinkel  wrote:
> > When you speak of NEWS, do you mean this?
> > https://github.com/php/web-news 
> >
> Negative. NEWS in all caps invariably refers to
> https://github.com/php/php-src/blob/master/NEWS which is a guaranteed
> merge conflict between branches.
>
> There are a few other places that mostly impact RMs like
> main/php_version.h and configure.ac
>
>
> Is there any chance the team would consider modifying the workflow a bit?
>
>
I thought about this (admittedly briefly) while replying and while I think
fixing NEWS would be... not impossible, I think the configure.ac and
php_version.h conflicts are a little more dicey.
Granted those are only a problem for RMs and we can build an escape hatch
for that.
But then conflicts in the rest of code aren't exactly uncommon, especially
in areas under heavy development like ext/opcache.
Basically, this is a hard problem and it's going to be a hard problem.

One alternative might be to switch to a pick model rather than a merge
model, but that just kicks the problem out a layer, it doesn't solve it.
What it does do is add a new opportunity for fixes to get missed.  -1 from
me on that.

-Sara

Re: [PHP-DEV] Changes to Git commit workflow

[Mike Schinkel]

> On Mar 30, 2021, at 9:50 AM, Sara Golemon  wrote:
> 
> On Tue, Mar 30, 2021 at 8:34 AM Mike Schinkel  > wrote:
> > When you speak of NEWS, do you mean this?
> > https://github.com/php/web-news  
> > >
> >
> Negative. NEWS in all caps invariably refers to 
> https://github.com/php/php-src/blob/master/NEWS 
>  which is a guaranteed merge 
> conflict between branches.
> 
> There are a few other places that mostly impact RMs like main/php_version.h 
> and configure.ac 
Gotcha. Thanks for the details on that Sara and George.

Is there any chance the team would consider modifying the workflow a bit?  I 
only ask if my input is helpful. If not, please disregard.

When teams I have been on in the past have found frequent merge conflicts we've 
restructured to move the frequently conflicting items to their own repo.

Then the high-conflict repo gets its own set of workflow rules and we used 
CI/CD and more recently GitHub Actions to incorporate the "releases" from the 
high-conflict repo into the main low-conflict repo.

Given those files you mentioned they seems to be about release management — and 
maybe harder for someone to inject a back-door into — so maybe a "release 
management" repo that gets merged in to php-src with GitHub Actions at 
appropriate times?

Again, please feel free to tell me to butt out if my thoughts are not being 
helpful here.

-Mike

Re: [PHP-DEV] Changes to Git commit workflow

[G. P. B.]

On Tue, 30 Mar 2021 at 14:34, Mike Schinkel  wrote:

>
>
> > On Mar 30, 2021, at 8:29 AM, Jakub Zelenka  wrote:
> >
> >
> >
> > On Tue, Mar 30, 2021 at 1:21 PM Jakub Zelenka  bu...@php.net>> wrote:
> >
> >
> > On Tue, Mar 30, 2021 at 12:47 PM Mike Schinkel  > wrote:
> >
> >
> > > On Mar 30, 2021, at 5:51 AM, Derick Rethans  der...@php.net>> wrote:
> > >
> > > On 30 March 2021 10:43:41 BST, Max Semenik  > wrote:
> > >> On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev
> > >> mailto:smalys...@gmail.com>>
> > >> 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 <
> 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.
> >
>
> When you speak of NEWS, do you mean this?
>
> https://github.com/php/web-news 
>
> -Mike
>

No he is talking about the NEWS file at the root of every branch which is
the changelog for what bugfixes have been applied to the branch.

Regards,

George P. Banyard

Re: [PHP-DEV] Changes to Git commit workflow

[Sara Golemon]

On Tue, Mar 30, 2021 at 8:34 AM Mike Schinkel  wrote:
> When you speak of NEWS, do you mean this?
> https://github.com/php/web-news 
>
Negative. NEWS in all caps invariably refers to
https://github.com/php/php-src/blob/master/NEWS which is a guaranteed merge
conflict between branches.

There are a few other places that mostly impact RMs like main/php_version.h
and configure.ac

-Sara

Re: [PHP-DEV] Changes to Git commit workflow

[Mike Schinkel]

> On Mar 30, 2021, at 8:29 AM, Jakub Zelenka  wrote:
> 
> 
> 
> 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
> >> mailto:smalys...@gmail.com>>
> >> 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.
> 

When you speak of NEWS, do you mean this?

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. 

So it is really more of a divide-and-conquer approach; automate what can be and 
manually handle what cannot be auto

Re: [PHP-DEV] Changes to Git commit workflow

[Jakub Zelenka]

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

Re: [PHP-DEV] Changes to Git commit workflow

[Jakub Zelenka]

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

Re: [PHP-DEV] Changes to Git commit workflow

[Mike Schinkel]

> 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.

I have actually been developing GitOps pipelines for my current client since 
February.

If you are unfamiliar with GitOps you might consider reading about from the 
links below?
 


Also, I just googled and found these, so I cannot endorse them having never 
used them, but they apparently show what can be done with GitHub PR and Merge 
Automation:

— Bulldozer is an auto-merge bot:
https://github.com/palantir/bulldozer  

— BorsNG is a merge bot for GitHub pull requests
https://bors.tech/

— Policy-bot evidentially allows merge rules to be declaratively specified, a 
real plus because then everyone who needs to know could see how the approval 
process works and who has access, at least by group:
https://github.com/palantir/policy-bot 

— Heres a simply article showing how to automate with Javascript and Probot:
https://freeletics.engineering/2019/09/09/automating-your-github-routine.html 
 

Hope this helps.

-Mike

[1] 
https://docs.github.com/en/github/administering-a-repository/managing-a-branch-protection-rule
[2] https://www.weave.works/technologies/gitops/ 

[3] https://www.gitops.tech/  
[4] https://harness.io/blog/devops/what-is-gitops/ 



> 
> It sounds like an annoying hurdle.
> 
> cheers,
> Derick
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Re: [PHP-DEV] Changes to Git commit workflow

[Derick Rethans]

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? 

It sounds like an annoying hurdle.

cheers,
Derick

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Changes to Git commit workflow

[Max Semenik]

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.


-- 
Best regards,
Max Semenik