# Changes to Git commit workflow - Thread: https://externals.io/message/113838 - Original archive: https://news-web.php.net/php.internals/113838 - Started by Nikita Popov on 2021-03-28T22:52:24+00:00 - Messages: 46 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/113838.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #113838 — Nikita Popov — 2021-03-28T22:52:24+00:00 URL: https://externals.io/message/113838#113838 Hi everyone, Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account). While investigation is still underway, we have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the git.php.net server. Instead, the repositories on GitHub, which were previously only mirrors, will become canonical. This means that changes should be pushed directly to GitHub rather than to git.php.net. While previously write access to repositories was handled through our home-grown karma system, you will now need to be part of the php organization on GitHub. If you are not part of the organization yet, or don't have access to a repository you should have access to, contact me at nikic@php.net with your php.net and GitHub account names, as well as the permissions you're currently missing. Membership in the organization requires 2FA to be enabled. This change also means that it is now possible to merge pull requests directly from the GitHub web interface. We're reviewing the repositories for any corruption beyond the two referenced commits. Please contact security@php.net if you notice anything. Regards, Nikita [1]: https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d and https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a --- ## #113839 — Nikita Popov — 2021-03-28T22:57:03+00:00 URL: https://externals.io/message/113838#113839 · In reply to: #113838 > Hi everyone, > > Yesterday (2021-03-28) two malicious commits were pushed to the php-src > repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how > exactly this happened, but everything points towards a compromise of the > git.php.net server (rather than a compromise of an individual git > account). > > While investigation is still underway, we have decided that maintaining > our own git infrastructure is an unnecessary security risk, and that we > will discontinue the git.php.net server. Instead, the repositories on > GitHub, which were previously only mirrors, will become canonical. This > means that changes should be pushed directly to GitHub rather than to > git.php.net. > > While previously write access to repositories was handled through our > home-grown karma system, you will now need to be part of the php > organization on GitHub. If you are not part of the organization yet, or > don't have access to a repository you should have access to, contact me at > nikic@php.net with your php.net and GitHub account names, as well as the > permissions you're currently missing. Membership in the organization > requires 2FA to be enabled. > > This change also means that it is now possible to merge pull requests > directly from the GitHub web interface. > > We're reviewing the repositories for any corruption beyond the two > referenced commits. Please contact security@php.net if you notice > anything. > > Regards, > Nikita > Assuming you do already have write access on GitHub, you can change the upstream repository of your local clone by running "git remote set-url origin git@github.com:php/php-src.git" (replacing php/php-src with the repository in question). Nikita --- ## #113840 — Paul Crovella — 2021-03-28T23:57:16+00:00 URL: https://externals.io/message/113838#113840 · In reply to: #113838 You might consider requiring commits be signed while you're at it. > > Hi everyone, > > Yesterday (2021-03-28) two malicious commits were pushed to the php-src > repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how > exactly this happened, but everything points towards a compromise of the > git.php.net server (rather than a compromise of an individual git account). > > While investigation is still underway, we have decided that maintaining our > own git infrastructure is an unnecessary security risk, and that we will > discontinue the git.php.net server. Instead, the repositories on GitHub, > which were previously only mirrors, will become canonical. This means that > changes should be pushed directly to GitHub rather than to git.php.net. > > While previously write access to repositories was handled through our > home-grown karma system, you will now need to be part of the php > organization on GitHub. If you are not part of the organization yet, or > don't have access to a repository you should have access to, contact me at > nikic@php.net with your php.net and GitHub account names, as well as the > permissions you're currently missing. Membership in the organization > requires 2FA to be enabled. > > This change also means that it is now possible to merge pull requests > directly from the GitHub web interface. > > We're reviewing the repositories for any corruption beyond the two > referenced commits. Please contact security@php.net if you notice anything. > > Regards, > Nikita > > [1]: > https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d > and > https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a --- ## #113841 — Sara Golemon — 2021-03-29T00:15:38+00:00 URL: https://externals.io/message/113838#113841 · In reply to: #113840 On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella wrote: > You might consider requiring commits be signed while you're at it. > > I suggested this as well, and even if we don't require it, we should STRONGLY encourage it. I've been signing my commits for several years now, it's not even that hard. --- ## #113842 — Rasmus Lerdorf — 2021-03-29T01:30:16+00:00 URL: https://externals.io/message/113838#113842 · In reply to: #113841 > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella > wrote: > > > […] > I suggested this as well, and even if we don't require it, we should > STRONGLY encourage it. > > I've been signing my commits for several years now, it's not even that > hard. > I think for php-src commits we can require it. For doc and other repos we can make it optional for now until people are more comfortable with it. -Rasmus --- ## #113843 — Gabriel Caruso — 2021-03-29T02:30:13+00:00 URL: https://externals.io/message/113838#113843 · In reply to: #113842 > > > > […] > I think for php-src commits we can require it. For doc and other repos we > can make it optional for now until people are more comfortable with it. > > -Rasmus > > We can require Signed Commits for the main active branches on GitHub: > https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-signed-commits We can create rules that requires that for all active maintained version of PHP. We can set that per repo, or in a organization level. - Gabriel Caruso --- ## #113844 — Ayesh Karunaratne — 2021-03-29T04:18:40+00:00 URL: https://externals.io/message/113838#113844 · In reply to: #113843 I think this is a great step forward. With commit signatures required, I think the person who merges a PR now needs to do so locally. [GitHub CLI](https://cli.github.com/) helps me a lot to locally checkout a PR quickly, and then rebase/squash with my own signature. Thanks to Levi Morrison and Nikita for the very quick response. > > > > > […] > > > > […] > > > We can create rules that requires that for all active maintained version of > PHP. > > We can set that per repo, or in a organization level. > > - Gabriel Caruso --- ## #113845 — Deleu — 2021-03-29T07:46:41+00:00 URL: https://externals.io/message/113838#113845 · In reply to: #113844 I think you only need to handle merges locally if the pull request author didn't sign their commits: > You can always push local commits to the branch if the commits are signed and verified. > You can also merge signed and verified commits into the branch using a pull request on GitHub. > However, you cannot squash and merge a pull request into the branch on GitHub unless you are the > author of the pull request. You can squash and merge pull requests locally. For more information, see > "Checking out pull requests locally ." Source: https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-signed-commits > I think this is a great step forward. > With commit signatures required, I think the person who merges a PR > now needs to do so locally. [GitHub CLI](https://cli.github.com/) > helps me a lot to locally checkout a PR quickly, and then > rebase/squash with my own signature. > > Thanks to Levi Morrison and Nikita for the very quick response. > > > […] > paul.crovella@gmail.com> > > […] > that > > […] > we > > […] > https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-signed-commits > > […] > of > > […] > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #113846 — Kalle Sommer Nielsen — 2021-03-29T07:50:14+00:00 URL: https://externals.io/message/113838#113846 · In reply to: #113838 Den man. 29. mar. 2021 kl. 01.52 skrev Nikita Popov : > While previously write access to repositories was handled through our home-grown karma system, you will now need to be part of the php organization on GitHub. If you are not part of the organization yet, or don't have access to a repository you should have access to, contact me at nikic@php.net with your php.net and GitHub account names, as well as the permissions you're currently missing. Membership in the organization requires 2FA to be enabled. How will this work for SVNROOT karma holders to grant karma to others going forward? -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #113847 — Paul Dragoonis — 2021-03-29T07:51:50+00:00 URL: https://externals.io/message/113838#113847 · In reply to: #113842 > > > > […] > I think for php-src commits we can require it. For doc and other repos we > can make it optional for now until people are more comfortable with it. > Hey Rasmus, This is a good compromise. However, if you leave phpweb repo without signed commits then we're at risk from XSS or similar attacks still, and the surface area is really big because literally everyone is accessing the site. Many thanks, Paul > -Rasmus --- ## #113848 — Paul Dragoonis — 2021-03-29T07:59:54+00:00 URL: https://externals.io/message/113838#113848 · In reply to: #113847 > > > > > > […] > > Hey Rasmus, > > This is a good compromise. > > However, if you leave phpweb repo without signed commits then we're at > risk from XSS or similar attacks still, and the surface area is really big > because literally everyone is accessing the site. > > Many thanks, > Paul > I also wanted to say; back when I was rebuilding our website a few years ago, when you pushed to master it would automatically deploy this to the live site. If we are compromised and we still automatically roll out to production, this would make it really easy for someone. Can someone check how we currently do this, and maybe we should reconsider auto production deploys, even if its temporary, to be on the safe side. > > > > > […] --- ## #113850 — Max Semenik — 2021-03-29T11:49:53+00:00 URL: https://externals.io/message/113838#113850 · In reply to: #113838 > changes should be pushed directly to GitHub rather than to git.php.net. Would it also make sense if direct pushes (bypassing the pull requests system) were disallowed completely? I can see multiple problems with direct pushes: 1) Someone trying to sneak in malicious code, like in the current incident (rarest but most damaging problem) 2) One dev pushes something, another dev disagrees, while the discussion continues, the potentially problematic commit stays on. Pre-merge reviews are much more natural for discussions. 3) Direct push bypasses CI to break tests, PRs can't be merged until the cause is identified and resolved (seems to be happening quite often) In my roughly one year around, I can now recall instances of each of these problems in php-src. -- Best regards, Max Semenik --- ## #113851 — G. P. B. — 2021-03-29T12:04:06+00:00 URL: https://externals.io/message/113838#113851 · In reply to: #113850 > > > > […] > > > Would it also make sense if direct pushes (bypassing the pull requests > system) were disallowed completely? I can see multiple problems with direct > pushes: > > 1) Someone trying to sneak in malicious code, like in the current incident > (rarest but most damaging problem) > 2) One dev pushes something, another dev disagrees, while the discussion > continues, the potentially problematic commit stays on. Pre-merge reviews > are much more natural for discussions. > 3) Direct push bypasses CI to break tests, PRs can't be merged until the > cause is identified and resolved (seems to be happening quite often) > > In my roughly one year around, I can now recall instances of each of these > problems in php-src. > > -- > Best regards, > Max Semenik > Although I agree that as a general rule many things should go through a PR, I think making it mandatory is going overboard, there is no need for a PR when one does a simple type fix in a document or comment, or trivial refactorings. I also don't know how this would interact with bug fixes needing to be merged upwards or cherry picks from the security repo which most of us have (and don't deserve) access to. Moreover, we have some flaky tests so CI can break for no reason and the CI matrix for master has a more complex nightly pipeline which does not run in a PR and thus make certain issues only apparent after the merge. IMHO making it required that direct pushes need to be signed commits is a better way forward. Best regards, George P. Banyard --- ## #113854 — Benjamin Morel — 2021-03-29T21:10:47+00:00 URL: https://externals.io/message/113838#113854 · In reply to: #113838 > > Hi everyone, > > Yesterday (2021-03-28) two malicious commits were pushed to the php-src > repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how > exactly this happened, but everything points towards a compromise of the > git.php.net server (rather than a compromise of an individual git > account). > That is scary. Can you disclose the contents of the commits? Are they specially designed to open a security hole, or to be harmful in another way? > While investigation is still underway, we have decided that maintaining > our own git infrastructure is an unnecessary security risk, and that we > will discontinue the git.php.net server. Instead, the repositories on > GitHub, which were previously only mirrors, will become canonical. This > means that changes should be pushed directly to GitHub rather than to > git.php.net. > This change will be welcome anyway! — Benjamin --- ## #113855 — bjorn.x.larsson@telia.com — 2021-03-29T21:32:16+00:00 URL: https://externals.io/message/113838#113855 · In reply to: #113854 Den 2021-03-29 kl. 23:10, skrev Benjamin Morel: > > […] > > That is scary. Can you disclose the contents of the commits? Are they > specially designed to open a security hole, or to be harmful in another way? > An article from The Hacker News and a tweet from Zerodium about the incident: -https://thehackernews.com/2021/03/phps-git-server-hacked-to-insert-secret.html -https://twitter.com/cBekrar/status/1376469666084757506 r//Björn L --- ## #113857 — Stanislav Malyshev — 2021-03-30T00:29:39+00:00 URL: https://externals.io/message/113838#113857 · In reply to: #113850 Hi! > > > > […] > > > 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. -- Stas Malyshev smalyshev@gmail.com --- ## #113859 — Max Semenik — 2021-03-30T09:43:41+00:00 URL: https://externals.io/message/113838#113859 · In reply to: #113857 On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev wrote: > Hi! > > > > […] > direct > > […] > > 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 --- ## #113860 — Derick Rethans — 2021-03-30T09:51:49+00:00 URL: https://externals.io/message/113838#113860 · In reply to: #113859 >On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev > >wrote: > > > […] >requests > > […] >with > > […] >(e.g. > > […] >am > > […] >working > > […] >etc. > > […] >investment > > […] >(though > > […] >can > > […] >to > > […] >days. > > […] > >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 --- ## #113861 — Mike Schinkel — 2021-03-30T11:46:48+00:00 URL: https://externals.io/message/113838#113861 · In reply to: #113860 > > > > > […] > > 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 > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #113862 — Jakub Zelenka — 2021-03-30T12:21:04+00:00 URL: https://externals.io/message/113838#113862 · In reply to: #113861 > > > > […] > wrote: > > […] > branch up through PHP 7.4, PHP 8.0, and then into master? > > […] > 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 --- ## #113863 — Jakub Zelenka — 2021-03-30T12:29:07+00:00 URL: https://externals.io/message/113838#113863 · In reply to: #113862 > > > On Tue, Mar 30, 2021 at 12:47 PM Mike Schinkel > wrote: > > > […] > 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 --- ## #113864 — Mike Schinkel — 2021-03-30T13:34:45+00:00 URL: https://externals.io/message/113838#113864 · In reply to: #113863 > > > > > > > > > > > > […] > > 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 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? --- ## #113865 — Sara Golemon — 2021-03-30T13:50:27+00:00 URL: https://externals.io/message/113838#113865 · In reply to: #113864 > 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 --- ## #113866 — G. P. B. — 2021-03-30T13:55:46+00:00 URL: https://externals.io/message/113838#113866 · In reply to: #113864 > > > > […] > bukka@php.net>> wrote: > > […] > > wrote: > > […] > derick@php.net>> wrote: > > […] > > wrote: > > […] > https://github.com/kubernetes/test-infra/tree/master/prow>) - I > > […] > branch up through PHP 7.4, PHP 8.0, and then into master? > > […] > and would then require a pointless PR? > > […] > via per-branch rules[1] where permissions and requirements can be assigned. > > […] > 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. > > […] > 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. > > […] > 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). > > […] > 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 --- ## #113867 — Mike Schinkel — 2021-03-30T14:08:26+00:00 URL: https://externals.io/message/113838#113867 · In reply to: #113865 > > > > > […] > 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 --- Next page: https://externals.io/message/113838.md?page=2