[PHP-DEV] Preliminary Polling

Morning internals, I've got a sort of fuzzy idea to make provisions in the RFC process for preliminary polling. It seems there are several situations where a preliminary poll makes sense, it would have made sense for the p++ discussion and saved us a week of wasted time. It also makes sense when

Re: [PHP-DEV] Removing old branches in php-src

I saw the list and the ages, what I didn't see was a justification for removing them. I think a proper analysis hasn't really been performed, for example the native-tls branch was merged after ng into the 7.0 series, and I didn't remove it because it serves as a reference point for the old vs the

Re: [PHP-DEV] Re: Implement lzma (xz?) compression (was Req #63880)

Note, while reading the code I noticed it doing some odd things with strings (see casting away constness in patch) ... this wants a maintainer, I was just getting the build going [and not volunteering] ... Cheers Joe PS. Sorry about double post ... On Mon, 19 Aug 2019 at 15:42, Joe Watkins

Re: [PHP-DEV] Re: Implement lzma (xz?) compression (was Req #63880)

Afternoon, Patch for php7: https://gist.github.com/krakjoe/549ec38161ecd1ad9b8f16f6cf18657e Run with it, or not ... Cheers Joe On Mon, 19 Aug 2019 at 14:43, Christoph M. Becker wrote: > Hi! > > On 19.08.2019 at 12:47, Tobias Frei wrote: > > > Today I was asked to contact this list about the

Re: [PHP-DEV] Remove special Zend karma

+1 Cheers Joe On Fri, 23 Aug 2019 at 10:33, Nikita Popov wrote: > Hi internals, > > We currently have separate karma for the Zend/TSRM directories in php-src. > I think this separation has become more annoying than useful at this point. > Most changes from newer contributors are approved on

[PHP-DEV] Defining the PHP Group

Morning internals, There is confusion among the community, and contained in the documented history of PHP on the wider internet. The Wikipedia states that PHP is developed by the PHP Group, in saying this it is (must be) referring to internals as a whole, but our own documentation names members

Re: [PHP-DEV] Defining the PHP Group

t; > Den søn. 15. sep. 2019 kl. 08.48 skrev Joe Watkins : > > > > Morning internals, > > > > There is confusion among the community, and contained in the documented > > history of PHP on the wider internet. > > > > The Wikipedia states that PHP is

Re: [PHP-DEV] Defining the PHP Group

Stas, > Not can't, shouldn't be. And I don't see any reason why we should stop saying that. Because it's a waste of everyone's time. The RFC process is the only one we have. > RFC process was not created to be sole governing body for PHP project and something that makes every vote mandatory for

Re: [PHP-DEV] Defining the PHP Group

Pierre, I repeat, there are no vetos, for anyone. Cheers Joe On Mon, 16 Sep 2019 at 11:04, Pierre Joye wrote: > On Mon, Sep 16, 2019 at 4:01 PM Pierre Joye wrote: > > > > On Mon, Sep 16, 2019 at 3:49 PM Joe Watkins wrote: > > > > > > Hi Pierre, > > &

Re: [PHP-DEV] Defining the PHP Group

Hi Pierre, > The RFC process defines a veto and could be applied when needed. Can you show me where that is defined please ? Cheers Joe On Mon, 16 Sep 2019 at 10:36, Peter Bowyer wrote: > On Sun, 15 Sep 2019 at 14:16, Zeev Suraski wrote: > > > > How can an undefined group have copyright

Re: [PHP-DEV] Defining the PHP Group

utor needs to recognize. I'm not going to discuss the legalities of what it means that the group hold copyright, you and I are not lawyers and that conversation is meaningless. Cheers Joe On Mon, 16 Sep 2019 at 11:35, Pierre Joye wrote: > Hi Joe, > > On Mon, Sep 16, 2019 at 4:25 PM

Re: [PHP-DEV] [RFC] Union Types v2 (followup on github usage)

> Because the PHP project should avoid depending on a privately owned centralized service for its technical discussions This is obviously your opinion, but you haven't actually told us why this is the case, and it's not at all obvious. > should not encourage (some would say force) people to use

Re: [PHP-DEV] Changing fundamental language behaviors

Zeev, I'm going to keep this really short and simple ... You don't have the authority to make unilateral decisions for PHP,. Nothing you are saying is going to have any effect, the people who actually work on the language will merge whatever is voted in. Cheers On Fri, 13 Sep 2019, 00:17 Mike

Re: [PHP-DEV] Changing fundamental language behaviors

I'm finished communicating with you. Cheers Joe On Fri, 13 Sep 2019 at 01:45, Zeev Suraski wrote: > > > On 13 Sep 2019, at 2:21, Joe Watkins wrote: > > Zeev, > > I'm going to keep this really short and simple ... > > > I'll do the same. > > You don't have the

[PHP-DEV] PHP 7.1.31 Released

Hi, The PHP development team announces the immediate availability of PHP 7.1.31. This is a security release which also contains several minor bug fixes. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.31 please visit our downloads page. Windows

Re: [PHP-DEV] Bringing Peace to the Galaxy

*alongside patch Cheers Joe On Fri, 9 Aug 2019, 09:33 Kris Craig, wrote: > On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote: > > > On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote: > > > > > > > > > > > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov > > wrote: > > > > > >> This is

Re: [PHP-DEV] Re: Bringing Peace to the Galaxy

Morning all, First, I want to say that I don't think the polarisation claimed to be occurring is actually occurring. The vast majority of internals voters appear to judge each RFC on it's own merit, while some of them give more weight to retaining bc than others and that effects their vote, they

Re: [PHP-DEV] GitHub RFC workflow

Evening Nikita, This is not really what we imagined when we started to discuss using github for pull requests - everything is going to end up on the wiki anyway. I do think this is a very reasonable first step, given how the discussion went on github and given the general feeling that we ought

Re: [PHP-DEV] GitHub RFC workflow

pen source project. I'm also not suggesting we move everything to github. I'm simply questioning the "owning all content" mantra because it doesn't make as much sense today as perhaps it once did. Cheers Joe On Mon, 4 Nov 2019 at 08:19, Pierre Joye wrote: > > > On Mon, Nov

Re: [PHP-DEV] GitHub RFC workflow

Morning, I don't want to follow this tangent for too long on owning content. Pierre, can you point to any contribution that would have been blocked by our use of github ? For all intents and purposes, the majority of new development does actually happen on github. As a result of us being

[PHP-DEV] Re: FFI & Security

:41, Christoph M. Becker wrote: > On 14.10.2019 at 09:44, Joe Watkins wrote: > > > Recently we voted on classification criteria for security bugs [1], we > > include under "not an issue" any issue that "requires invocation of > > specific code, which may be valid bu

Re: [PHP-DEV] GitHub RFC workflow

ake a whole lot of practical sense. If we can't find practical reasons not to take advantage of what is being offered, then I don't think we should put theoretical problems in the way of progress. Cheers Joe On Mon, 4 Nov 2019 at 12:57, Pierre Joye wrote: > > > On Mon, Nov 4, 2019,

[PHP-DEV] PHP 7.1.33 Released

The PHP development team announces the immediate availability of PHP 7.1.33. This is a security release. All PHP 7.1 users are encouraged to upgrade to this version. For source downloads of PHP 7.1.33 please visit our downloads page. Windows binaries can be found on the PHP for Windows site. The

[PHP-DEV] Extension: ilimit

Hi all, I intend to publish (or have someone else publish) https://github.com/krakjoe/ilimit to pecl in the coming days, any comments/objections/other relevant noises ? Cheers Joe

[PHP-DEV] FFI & Security

Morning all, Recently we voted on classification criteria for security bugs [1], we include under "not an issue" any issue that "requires invocation of specific code, which may be valid but is obviously malicious". I would like to add an explicit clause under the "not an issue" section for

Re: [PHP-DEV] Computing code coverage on Azure Pipelines

I am current maintainer of gcov server, I planned this kind of integration with azure, so once again, thanks. +1 to ditching gcov.php.net, we are terrible at infra ... On Mon, 14 Oct 2019, 16:13 Nikita Popov, wrote: > On Mon, Sep 30, 2019 at 2:30 PM Gerard Roche > wrote: > > > > gcov.php.net

Re: [PHP-DEV] Re: VCS Account Request: nicolasgrekas

I just want it to be noted that I requested that the decision is reconsidered also. I think, plain and simple, a mistake has been made. Cheers Joe On Wed, 15 Jan 2020 at 10:40, Pierre Joye wrote: > On Tue, Jan 14, 2020, 8:08 PM Peter Cowburn wrote: > > > On Tue, 14 Jan 2020 at 12:27, Nicolas

Re: [PHP-DEV] Improving output of syntax errors

Nicely done. No need for an RFC. Thanks. On Sunday, 28 June 2020, Stanislav Malyshev wrote: > Hi! > > > For more examples, see: > > https://rwec.co.uk/x/php-parse-errors/comparison.html > > > > The patch can be reviewed at: https://github.com/php/php-src/pull/5722 > > I think this is great,

Re: [PHP-DEV] Rename Fiber::this() to Fiber::getCurrent()

This doesn't look like the sort of detail we need to vote on. It would be nice if this were made in time for the migration guide and other doc to be prepared for 8.1. Let's move forward, please ... Cheers Joe On Tue, 15 Jun 2021 at 21:54, Larry Garfield wrote: > On Tue, Jun 15, 2021, at 2:01

Re: [PHP-DEV] [RFC] is_literal

Morning, https://3v4l.org/nJhc1/rfc#focus=rfc.literals It's not so much a bug as a side effect or quirk. Note that, the result is correct, in the sense that you do have a literal string - it is not marking an unsafe string as safe. It's just that existing implementation details - RETURN_CHAR

Re: [PHP-DEV] [RFC] is_literal

Afternoon all, While this is not at all my idea, I wrote the patch, so my words may seem bias/hollow. Still, here are some words ... In the past this kind of feature would have been extremely invasive, it would have had so many edges because of the way we handled strings that it was never really

Re: [PHP-DEV] [Vote] Partial Function Application

I'd like to note a couple of things ... The behaviour of nullsafe and strict types being unspecified in the RFC would allow us to solve those problems later. The behaviour of strict types right now is objectively wrong, the partial takes strictness from the application site, so as Nikita already

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Nobody has demonstrated that "string" . int can lead to anything but mistakes. It CANNOT lead to injection, and that's what we're talking about, we're not talking about a function that protects you from all possible security concerns or bugs. The actual definition of injection matters, when we

Re: [PHP-DEV] [RFC] is_literal

15 Jun 2021 at 10:56, Claude Pache wrote: > > > Le 15 juin 2021 à 09:19, Joe Watkins a écrit : > > Morning, > > https://3v4l.org/nJhc1/rfc#focus=rfc.literals > > It's not so much a bug as a side effect or quirk. > > Note that, the result is correct, in the sense th

Re: [PHP-DEV] [RFC] is_literal

Just to explain this tracking of longs. We can track strings because there's space to do that in GC info which recounted types all have. Where things aren't recounted there is no usable space on the value to store the literal flag without disabling some internal assumptions about type flags. We

Re: [PHP-DEV] [RFC] is_literal

Refcounted* not recounted ... Predictive text on phone ... Cheers Joe On Friday, 18 June 2021, Joe Watkins wrote: > Just to explain this tracking of longs. > > We can track strings because there's space to do that in GC info which > recounted types all have. > > Where thing

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

There's a couple of typos in the RFC, which Larry will fix when he has time. There was also a typo in patch, and a fault in patch. All fixed. pending tests, 3v4l won't update until tomorrow. Cheers Joe On Fri, 11 Jun 2021 at 13:02, Guilliam Xavier wrote: > Sorry, me again :s I have tested

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

Morning, Still I think heavy use has to be the exception, especially heavy use where readline is not available (because it's questionably useful). Cheers Joe On Wed, 12 May 2021 at 11:39, Pierre wrote: > Le 12/05/2021 à 11:29, Joe Watkins a écrit : > > Morning Nikita, > > >

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

Morning Nikita, +1 on the change to cli. It can't really be a default extension right now because readline license is not compatible: https://github.com/php/php-src/pull/3823 Even without the license problem, I'm not convinced of the value of adding the dependency: Because of this long

[PHP-DEV] Bugsnet

Morning internals, We have a spam problem on bugsnet, it's not a new problem. Nikita had to waste time deleting 20 odd messages from bugsnet yesterday and this is a common, daily occurrence. We clearly don't have time for this. Quite aside from spam problems, bugsnet is hidden away in a dark

[PHP-DEV] Re: Bugsnet

Hi Stas, I did mention that we're leaving aside the sec issue for now. > Let me list all it is lacking that we have right now, with current old and dusty bugs: 1)

Re: [PHP-DEV] Re: Bugsnet

Hi all, I shouldn't have said we can "just" move ... I'm not supposing it will be easy. We can "just move", in about the same sense that we can "just move" today. Considering the difficulty of problems we do not currently have is a waste of time. Cheers Joe On Sun, 9 May 2021 at 10:08,

[PHP-DEV] Consensus Gathering: is_initialized

Hi internals, In response to: https://bugs.php.net/bug.php?id=78480 I implemented: https://github.com/php/php-src/pull/7029 Not absolutely convinced that it's a good idea, I asked Nikita to review, and he's unconvinced also and suggested a discussion should be started. You can read both of our

Re: [PHP-DEV] Consensus Gathering: is_initialized

helps you to decide if it's good or bad, but I'm particularly interested in your concrete answer to the question of badness. Cheers Joe On Wed, 26 May 2021 at 12:30, Marco Pivetta wrote: > > > On Wed, May 26, 2021 at 12:14 PM Joe Watkins wrote: > >> Hi internals, >> >&

Re: [PHP-DEV] Consensus Gathering: is_initialized

uch talked myself out of it at this point already ... I'm hearing what I expected to hear. Cheers Joe On Wed, 26 May 2021 at 14:57, Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > > > śr., 26 maj 2021 o 12:14 Joe Watkins napisał(a): > >> Hi internals, >&

Re: [PHP-DEV] Consensus Gathering: is_initialized

Thanks for all the input everyone, very successful consensus gathering exercise. Since the response was pretty overwhelmingly negative, I think we can just stop here. I've closed the PR and wrapped up the FR. Anyone is of course free to pursue the RFC that would be required, however ill

[PHP-DEV] Pear SSL Cert Expired

Can someone fix it please ? Cheers Joe

Re: [PHP-DEV] FFI Type Reflection API

Hi Dmitry, It doesn't make sense to wait another year for this, and since it's self contained it's fine to merge into 8.1 when ready. Cheers Joe On Wednesday, 7 July 2021, G. P. B. wrote: > On Wed, 7 Jul 2021 at 10:31, Dmitry Stogov wrote: > > > Hi, > > > > Last week, at a PHP conference, we

Re: [PHP-DEV] [RFC] Name issue - is_literal/is_trusted

Please, stop spamming us with the same comments. Cheers Joe On Sat, 26 Jun 2021 at 14:25, Dan Ackroyd wrote: > On Fri, 25 Jun 2021 at 00:57, Craig Francis > wrote: > > > Dan Ackroyd wrote: > > > Please can you go into some detail about what you think people are > > > meant to do when they

[PHP-DEV] Fake Closure Comparison

Morning internals, While discussing some of the details of the first class callable RFC, it became apparent that fake closures (created by Closure::fromCallable) are not currently comparable in a useful way. Although this is not directly related to the first class callable feature, it's likely

[PHP-DEV] Re: Fake Closure Comparison

The test included is quite comprehensive. Cheers Joe On Friday, 9 July 2021, Larry Garfield wrote: > On Fri, Jul 9, 2021, at 4:51 AM, Nikita Popov wrote: > > On Fri, Jul 9, 2021 at 10:45 AM Joe Watkins wrote: > > > > > Morning internals, > > > > >

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

before this > one > > > > goes to a vote. > > > > > > Hi again. > > > > > > With PFA being declined, I've again reworked the Pipes RFC. > > > > > > 1) It now does not use PFA in any examples, but it does use Nikita's > >

Re: [PHP-DEV] [RFC] [VOTE] is_literal

9 > > > > The proposal is to add the function is_literal(), a simple way to > identify > > if a string was written by a developer, removing the risk of a variable > > containing an Injection Vulnerability. > > > > This implementation is for literal strings ONLY

Re: [PHP-DEV] Retire distributions repo in favor of something more suitable

Morning all, I'd be very up for that ... The "alternative workflow" in this document seems reasonable for us to use (or modify for use): https://wiki.debian.org/Creating%20signed%20GitHub%20releases RE vendor lock-in: Any provider we may move to in the future is going to have to be based on

Re: [PHP-DEV] [RFC] Property accessors

I haven't read it properly yet (been watching a little), but I just wanted to say thanks for the refreshing honesty :) Cheers Joe On Tue, 4 May 2021 at 12:34, Nikita Popov wrote: > Hi internals, > > I'd like to present an RFC for property accessors: >

Re: [PHP-DEV] Retire distributions repo in favor of something more suitable

That's a good point. I suppose the most we can do is prevent accidental committing of such things. Appears to be two "solutions" ... We could distribute a pre-commit hook, which is somewhere between "not bad", and "pretty awkward" if your git installation is old. We could setup one of the

Re: [PHP-DEV] Retire distributions repo in favor of something more suitable

of the protection that version files used to have. It's not so simple ... Cheers Joe On Wed, 28 Apr 2021 at 16:18, Joe Watkins wrote: > That's a good point. > > I suppose the most we can do is prevent accidental committing of such > things. > > Appears to be two "solutions" ... &

[PHP-DEV] PHP 8.1 Release Manager Selection

Afternoon all, I have decided to volunteer to mentor the 8.1 release managers as a veteran release manager. We have many volunteers from the community for this release, and intend to hold a vote to choose two of them to be mentored by myself. Expect more communication to follow, some slight

Re: [PHP-DEV] wiki.php.net upgrade

Any use case we have for content or collaboration is best served by whomever or whatever is going to secure that content or ability to collaborate. Nobody has updated the wiki in several years, despite warnings, and two very public breaches of security that we know about. We don't have the

Re: [PHP-DEV] wiki.php.net upgrade

seems ok. > > Can we test it in the production environment, but not yet release it? > > [1] https://github.com/php/web-wiki/pull/15 > > — > wbr, > Sergey Panteleev > > > From: Joe Watkins > Date: Thursday, 8 April 2021, 11:23 > To: Stanislav Malyshev &

Re: [PHP-DEV] [VOTE] Nullable intersection types

and that degrades my confidence that making the change this late even if it does pass is a good idea. Cheers Joe On Mon, 16 Aug 2021 at 10:04, Nikita Popov wrote: > On Mon, Aug 16, 2021 at 9:45 AM Joe Watkins wrote: > >> Morning all, >> >> The initial RFC was clear that nulla

Re: [PHP-DEV] [VOTE] Nullable intersection types

Please rearrange and add words as necessary, so that they makes sense :) "... however that doesn't seem to have been widely understood". Cheers Joe On Monday, 16 August 2021, Joe Watkins wrote: > Morning all, > > The initial RFC was clear that nullability was not

Re: [PHP-DEV] [VOTE] Nullable intersection types

Morning all, The initial RFC was clear that nullability was not supported, however that doesn't seem to be have widely understood. When I said we should move forward I did imagine that there was some consensus about the syntax we should use if we were to support nullability. As this

Re: [PHP-DEV] Shut down gcov.php.net

+1, this was always the long term plan. Cheers Joe On Wednesday, 4 August 2021, Nikita Popov wrote: > On Wed, Aug 4, 2021 at 2:25 PM Christoph M. Becker > wrote: > > > Hi all, > > > > I suggest to shut down altogether. It is barely > > maintained for quite a while: PHP

Re: [PHP-DEV] Unbreak git.php.net links?

This seems reasonable. I wonder if we could log the redirects so that we can obtain the list of links and update accordingly so that we may eventually retire the domain without breaking stuff. Cheers Joe On Monday, 4 October 2021, Stanislav Malyshev wrote: > Hi! > > I know we're no longer

Re: [PHP-DEV] Unbreak git.php.net links?

I didn't think about external links ... I guess then redirecting would be best. The nameserver configuration is still as it was (I think), so it's probably best to setup the NS to point at web and then someone can do the work in the web repo (I suppose). Cheers Joe On Mon, 4 Oct 2021 at 08:01,

Re: [PHP-DEV] Unbreak git.php.net links?

October 2021, Joe Watkins wrote: > This seems reasonable. > > I wonder if we could log the redirects so that we can obtain the list of > links and update accordingly so that we may eventually retire the domain > without breaking stuff. > > Cheers > Joe > > On Mon

Re: [PHP-DEV] intersection types and null for defaults, properties and return types

Agree, an RFC looks like the only way. This is not worth delaying a release for, nor is it worth postponing the feature freeze date. It seems reasonable to fix this after freeze, would prefer to reach consensus before RC stage. Cheers Joe On Tue, 20 Jul 2021 at 13:07, Nikita Popov wrote: >

Re: [PHP-DEV] [RFC] Nullable intersection types

This is not a new feature. This is a detail of a feature that was not well understood for whatever reason. That is why we are willing to fix it after freeze. I would ask anyone voting to vote on the basis of the detail and leave timing to be the problem of release managers. Voting negatively

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

Morning internals, Today, some friends of the project, people we consider leaders even, are waking up in a war zone. They are living an unimaginable horror, and as I sit here and type, I fight back tears for them ... I am afraid for them, their families, their lives. The feeling of helplessness

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

Hi all, Applications are open for a week. Two people will be chosen by election and a veteran will help them. If no other veteran comes forward I will continue in that role for 8.2. Cheers Joe On Tue, 26 Apr 2022, 21:21 Eric Mann via internals, wrote: > I'm new to this mailing list as I'd

Re: [PHP-DEV] Set SA_ONSTACK in zend_sigaction External

Hi Kevin, Master should be targeted, no RFC is required, and the patch looks fine to me. Cheers Joe On Thu, 22 Sep 2022, 14:56 Kévin Dunglas, wrote: > Hi, internals! > > It's been a while. > > I'm currently working on a new SAPI for web servers written in Go. > Many virtual machines,

<    1   2   3   4   5   6