Re: [PHP-DEV] Where to document configuration option changes?

[Peter Kokot]

On Wed, 4 Sept 2024 at 15:07, Christoph M. Becker  wrote:
>
> Hi all,
>
> that issue came up the other day on a pull request[1], but since it is
> not particularly related to any single PR, I wanted to ask here for
> clarification.
>
> This is about changes to `./configure` options of php-src, and whether
> these should be documented in UPGRADING or UPGRADING.INTERNALS.  For the
> master branch, most such changes are currently documented in
> UPGRADING.INTERNALS, but a few are in UPGRADING.
>
> In my opinion these changes should be documented in UPGRADING, but not
> in UPGRADING.INTERNALS, because they are relevant for users who build
> PHP themselves, packagers (aka distro managers) and the documentation
> team, and neither of these is supposed to read UPGRADING.INTERNALS.  And
> I believe that it has been done this way in the past.
>
> What do you think?
>
> On a general note, it might be reasonable to properly document what
> should go into UPGRADING, UPGRADING.INTERNALS and NEWS; that seems to be
> generally somewhat unclear; sometimes there are entries in NEWS *and*
> UPGRADING for the same changes, what appears to be duplicate content to me.
>
> [1] 
>
> Christoph

I've checked some of PHP-5.x and PHP-7.x branches and it seems that
we've started adding these configure options also in
UPGRADING.INTERNALS more consistently somewhere in PHP-7.4 (probably).
Otherwise, they are noted here and there inconsistently. So far there
was no specific guideline, where to document these.

Issue here is that the person that needs to adjust their build
configuration or Linux repository package scripts, they only need to
see what configure options, need adjustments and which dependencies
need to be updated. And then the fun starts with adjusting all the
patches and everything but theoretically a single list of these types
of changes would help. Browsing the entire UPGRADING document might be
a bit confusing for this. Also, some configuration options changes are
related only to Autotools build system and some to JScript Windows
build system. Ideally, this type of page
https://www.php.net/manual/en/migration83.php would also include this
build system specifics that are needed to migrate PHP. This is in most
cases only relevant to a smaller number of people actually. PHP
developers in most cases don't build PHP from scratch.

Re: [PHP-DEV] Native SSL support in Phar extension

[Peter Kokot]

On Mon, 26 Aug 2024 at 20:05, Calvin Buckley  wrote:
> As such, it might be a bit tricky for people on Windows/AIX; the easiest
> solution if PHAR is using the openssl extension's symbols would be to not
> build the openssl extension as shared.

I've just checked Windows build and the PHP downloaded from PHP.net
and it seems to already use the openssl and phar extensions like this.
The ext/openssl is built as shared (the php_openssl.dll) and phar is
built into the php binary (which doesn't matter much here I think).
So I think this means one platform to worry about this issue here less.

About the AIX it's totally possible that this is still an issue. I'll
need to check it out in more detail at some point. If I understand the
issue mentioned in the blog post it is something else - two different
OpenSSL versions being linked. Which is of course bad. And this
removal is moving towards this direction also. OpenSSL being linked
only in ext/openssl. And in PHP different OpenSSL versions linked
could happen in a few other places as well - the curl, ftp and mysqlnd
extensions.

Well, this issue sounds complicated for PHP 8.4, so we can do it in
the next version then.

[PHP-DEV] Native SSL support in Phar extension

[Peter Kokot]

Hello,

There came up another idea/issue about the Phar extension and its
native SSL support.

As you might know or not, when building PHP:

./configure --with-openssl --enable-phar

the Phar extension will get so-called native SSL enabled through
OpenSSL directly. However, when built like this:

./configure --with-openssl=shared --enable-phar=shared
or
./configure --with-openssl=shared --enable-phar

the SSL support will depend on whether the ext/openssl is loaded and
enabled during PHP runtime. SSL support in both cases is done with
different pieces of code (one is using ext/openssl functions and the
other one - native SSL - is using OpenSSL calls directly). Also in
phpinfo output there is a bit of different info given based on the SSL
type.

On Windows there is also a slight inconsistency at the moment where
there is obsolete --enable-phar-native-ssl configure option available
which is using missing libeay32 library.

My first understanding was that native SSL is "better" as it uses
OpenSSL directly but it turned out that the code is outdated:
https://github.com/php/php-src/pull/14578

So, a new suggestion here is to remove the native SSL support in phar
extension in favor of using a PHP openssl extension's API (or better
call it function calls for the time being):
https://github.com/php/php-src/pull/15574

This would make the SSL support in phar more consistent because now
people aren't even aware of this. For example, on Alpine Linux default
packages there is openssl extension used in phar extension and on
Ubuntu's default packages there is this native SSL used.

Does anyone see any issues with removing the native SSL support in
Phar extension? Let me know. Ideally we would remove it in PHP 8.4
otherwise in the version after that...

Re: [PHP-DEV] Anyone willing to help out 3v4l ?

[Peter Kokot]

On Tue, 13 Aug 2024 at 01:57, Juliette Reinders Folmer
 wrote:
>
> Hi all,
>
> I suppose everyone is aware of 3v4l.org and a lot of us use it on a regular 
> basis.
>
> 3v4l also auto-builds the PHP "master" branch every night to allow for 
> testing with the latest and greatest PHP version and comparing changes in 
> behaviour against older PHP versions.
>
> Now, the auto-build of the PHP "master" branch broke a couple of days ago 
> (August 9th to be exact). [1]
> The timing is a bit unfortunate, what with the bulk of the PHP 8.4 
> deprecations going in over the last few days.
>
> The compilation error they are seeing is this:
> ```
>
> sapi/phpdbg/phpdbg_lexer.l:8:10: fatal error: phpdbg_parser.h: No such file 
> or directory
>  #include "phpdbg_parser.h"
>   ^
> compilation terminated.
> make: *** [Makefile:570: sapi/phpdbg/phpdbg_lexer.lo] Error 1
>
> ```
>
> Now, I know nothing about building PHP from source, but figured someone here 
> may straight away know the source of this issue (and possibly how to fix it 
> ?).
> If so, leaving a comment on the below linked issue would be greatly 
> appreciated!
>
> Please forgive me if asking this here is not appropriate, but a quick pointer 
> could help immensely!
>
> Thanks for considering.
>
> Juliette
>
> 1: https://github.com/SjonHortensius/3v4l_org/issues/22
>

Should be fixed via https://github.com/php/php-src/pull/15373

Re: [PHP-DEV] Require C11 in PHP 8.4

[Peter Kokot]

On Mon, 5 Aug 2024 at 19:15, Christoph M. Becker  wrote:
> But what about other compilers we support on non Windows platforms
> currently, like clang, Apple's clang, Solaris Studio and maybe some more
> we don't even know about.

Might be worth noting here that from what I've tested so far that PHP
cannot be built currently with Solaris Studio compiler and most likely
any other compiler out of the range of MSVC, GCC and Clang (including
the AppleClang). There are errors in the configure steps due to not
properly checked linker flags and there are lots of warnings and
errors produced during the make step. So, basically the list of
"supported" and heavily tested compilers is at this point: GCC and
Clang.

I find this strange, but it also makes sense to not be able to support
a wide variety of compilers without having additional CI builds.

A nice list of "relevant" compilers from the build system point of
view for some overview:
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html

Re: [PHP-DEV] Sync CODEOWNERS

[Peter Kokot]

On Thu, 18 Jul 2024, 16:32 Ilija Tovilo,  wrote:

> Hi Christoph
>
> On Thu, Jul 18, 2024 at 2:09 PM Christoph M. Becker 
> wrote:
> >
> > So I suggest to sync CODEOWNERS for all active branches (and maybe even
> > security branches).
> >
> > What do you think?
>
> I think back when it was introduced it wasn't clear (at least to me)
> that PRs would request reviews based on the CODEOWNERS file of the
> target branch, rather than the default branch. Given that's how it
> works, syncing it in all active branches makes sense to me.
>
> Ilija
>

I think that nothing will help solve this issue but to write also some
comment in that file on top to send updates to the earliest supported
branch, and not the master branch only.

We were resolving this in the past not so long ago:
https://github.com/php/php-src/pull/13591

>

[PHP-DEV] Support for pkg-config .pc files

[Peter Kokot]

Hello,

There is another pull request in preparation that I'd like to squeeze in
the PHP-8.4 branch if it will possible to wrap it up until the feature
freeze milestone:
https://github.com/php/php-src/pull/13755

In short, pkg-config is *nix command line utility to query installed
libraries on the system:
https://en.wikipedia.org/wiki/Pkg-config
https://people.freedesktop.org/~dbn/pkg-config-guide.html

And pkgconf is a compatible maintained continuation/fork that many
distributions might also use.

Each library creates a so-called .pc file, for example, php.pc which is
installed to the pkgconfig subdirectory. For example,
/usr/lib/x86_64-linux-gnu/pkgconfig/php.pc

.pc file is created from a template .pc.in and gets some placeholders
replaced during the configuration phase of building to get the library
name, include flags etc.

PHP already extensively relies on pkg-config's interface for finding
certain dependencies during the build (libxml2, SQLite, OpenSSL, curl...)
but so far never implemented its own .pc file(s).

PHP could have two such .pc files. One for a global PHP installation as a
whole that PHP extensions can use (php.pc) and one for the embed SAPI to
embed PHP into an application (php-embed.pc)

Its usage is very similar to php-config script, i.e. getting build details.

See PR for details, I'll update it on the way what can be done.

Let me know if that's fine or is there some concern.

[PHP-DEV] Bumping minimum Apache version to 2.4

[Peter Kokot]

Hello,

Perhaps you're not aware that the PHP build system currently still
supports building apache2handler SAPI for Apache 2.0 and 2.2 branches.
Apache 2.2 has been marked as EOL in December 2017 and doesn't receive
security patches. Also, most Linux distributions and packages mostly
support 2.4 as minimum by now.

See: 
https://forum.apachehaus.com/news-general-discussion/apache-2-2-users-your-time-is-running-out/

In this pull request, support for Apache 2.0 and 2.2 is being removed:
https://github.com/php/php-src/pull/14664

In Autotools build system, there isn't much changed except the version
is checked, on Windows there will be configure option
--enable-apache2-2handler removed and --enable-apache2-4handler
becomes an alias of --enable-apache2handler configure option.

Let me know if you find any server that can't or hasn't been upgraded
to Apache 2.4 yet and if this should be postponed after PHP 8.4,
otherwise merge is on its way for PHP 8.4.

Re: [PHP-DEV] Bumping minimum PostgreSQL version to 10.0

[Peter Kokot]

On Mon, 17 Jun 2024 at 19:16, Matteo Beccati  wrote:
>
> Hi,
>
> Il 17/06/2024 19:03, Peter Kokot ha scritto:
> > On Mon, 17 Jun 2024 at 18:58, Pierre  wrote:
> >>
> >> Would id affect the possibility to use an old PostgreSQL (eg. 9.6) via
> >> PHP (PDO or ext-pgsql) ?
> >>
> >> If so, it might be a dangerous move for oldest projects, you sometime
> >> can upgrade PHP and your software easily, but can't upgrade the database
> >> server.
> >>
> >> Regards,
> >>
> >> Pierre
> >
> > Yes, after such version increase it would affect PDO PGSQL extension
> > also and you'd need to upgrade the database. In the PR there is also
> > 9.6 mentioned as one version earlier as an alternative. I'm fine with
> > 9.6 also but PHP-8.4-dev code will need to be adjusted further.
>
> Please correct me if I'm wrong, but the basic capability of connecting
> to an older version shouldn't be compromised. It's only the build
> process requiring libpq > 10.
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/

When building for a certain PostgreSQL version, the pq library gets
linked to the extension and then this PostgreSQL version needs to be
used, yes. If you build for 10.0, then you need to use that exact
version. Linux packages have this resolved by dependencies on the
packages so when you install the extension it will work for that
distribution PostgreSQL package.

Re: [PHP-DEV] Bumping minimum PostgreSQL version to 10.0

[Peter Kokot]

On Mon, 17 Jun 2024 at 18:58, Pierre  wrote:
>
> Would id affect the possibility to use an old PostgreSQL (eg. 9.6) via
> PHP (PDO or ext-pgsql) ?
>
> If so, it might be a dangerous move for oldest projects, you sometime
> can upgrade PHP and your software easily, but can't upgrade the database
> server.
>
> Regards,
>
> Pierre

Yes, after such version increase it would affect PDO PGSQL extension
also and you'd need to upgrade the database. In the PR there is also
9.6 mentioned as one version earlier as an alternative. I'm fine with
9.6 also but PHP-8.4-dev code will need to be adjusted further.

[PHP-DEV] Bumping minimum PostgreSQL version to 10.0

[Peter Kokot]

Hello,

we're thinking of bumping the minimum PostgreSQL version supported by PHP from
current version 9.1 to version 10.0:
https://github.com/php/php-src/pull/14540

A list of PostgreSQL versions and their EOL dates can be seen at
https://en.wikipedia.org/wiki/PostgreSQL

The versions coverage by Linux/Unix distributions can be found at
https://pkgs.org

For example:
- https://pkgs.org/search/?q=libpq
and
- https://pkgs.org/search/?q=postgresql

This is aligning with CentOS 7 EOL in June 2024 and CentOS 8. PostgreSQL 10 is
already EOL but to provide easier migration for packages, I think such
increase is ok.

Anyone have any concerns or thoughts about this?

[PHP-DEV] GitHub milestones

[Peter Kokot]

Hello,

I was wondering if it would be useful to add GitHub milestones for the
PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
https://github.com/php/php-src/milestones

Because some pull requests might target versions after the PHP-8.4 and it
might be useful to have them additionally sorted to not forget about them.
Not to tag all PRs of course but only those which are meant to go into some
of the future branches.

Thanks.

Re: [PHP-DEV][RFC][Vote] grapheme_cluster for str_split, grapheme_str_split function

[Peter Kokot]

On Tue, 26 Mar 2024 at 06:41, youkidearitai  wrote:
>
> Hi, Internals
>
> Sorry I mistake.
> Send again.
>
> grapheme_str_split going to "Voting" phase.
> Vote end is 10th April 00:00 GMT
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -

And a link is this one for those wondering where to click:
https://wiki.php.net/rfc/grapheme_str_split

Re: [PHP-DEV] is this thing on?

[Peter Kokot]

On Tue, 5 Mar 2024 at 01:27,  wrote:
>
> > The VSC part from github (hosting our code), can very easily be ported. 
> > Issues, discussions etc can not.
> >
> > With the ongoing enshittification of most of the Internet due to 
> > advertising and tracking, we'd be negligent not hosting and owning our own 
> > content (including our issue tracker, but that ship has sailed now).
>
> PHP actually recently moved from a self-hosted VCS to github due to a hack 
> that compromised php's source code, moving back to a self-hosted instance 
> seems like a downgrade.
>
> However, if that's being discussed, it can be done properly, i.e. with a 
> self-hosted gitlab instance, which also provides issues, projects, CI, 
> basically the full devops experience, that would be the perfect chance to 
> also move the mailing list and php wiki to gitlab (which is how many FOSS 
> projects work currently, I.e. wayland, xorg, mesa, pipewire, asahi use the 
> gitlab.freedesktop.org gitlab instance, arch linux has its own gitlab 
> instance (which is also used for RFCs)).
>
>
> > Email has been around for half a century. Will things like Slack, Discord, 
> > and the like still be operational and allow access to our archives in 
> > another 25 years? I'm almost certain it won't be.
>
> No one is proposing to move the issue tracker to discord, slack or telegram: 
> those are messengers, and should not be used as support forums for such a 
> major language, mainly because they're non-indexable.
>
> Regards,
> Daniil Gentili
>

Interesting thing with GitHub discussions, issues and PRs is that they
are also like some sort of temporary chat. In my experience whatever
we've discussed on PHP GitHub places was never actually very important
for the project maintainers nor taken seriously. Mailing list was
always a bit more serious and taken with a slight priority.
Interesting is that we have discussed something on GitHub but then
later people have implemented something completely different or
completely forgot about the thing we've discussed on GitHub. I think
that GitHub requires a lot of effort to participate. You can't only
discuss it from your mobile phone. There actual implementations need
to be done. And by all means, GitHub PHP places are all there, waiting
for people to jump in and write a word or two where they feel needed.

Re: [PHP-DEV] php-src docs

[Peter Kokot]

On Mon, 12 Feb 2024 at 12:13, Ilija Tovilo  wrote:
>
> Hi Yuya
>
> It seems you accidentally sent your response to me instead of the list.
>
> On Sun, Feb 11, 2024 at 5:10 PM youkidearitai  wrote:
> >
> > 2024年2月11日(日) 21:18 Ilija Tovilo :
> > >
> > > Hi everyone.
> > >
> > > I would like to start an initiative to centralize documentation of the
> > > PHP internals.
> > > https://github.com/php/php-src/pull/13338
> > > https://iluuu1994.github.io/php-src/ (will be moved to php.github.io
> > > once merged)
> > >
> > > Let me know of any thoughts and suggestions you might have.
> >
> > Hi, Ilija.
> > Thank you for your great suggestion.
> >
> > It seems make sense to have a set of documents about the structure of
> > php-src in php-src.
> > Easily create pull requests to them.
> >
> > Although I have to learn reStructuredText, It is not seems major problem.
>
> For some context, I initially planned to go with the mdBook from the
> Rust project (https://github.com/rust-lang/mdBook/) as Markdown is a
> bit more approachable. After writing the sample zval chapter, I
> noticed some pain points in terms of formatting, most significantly
> tables. That said, reStructuredText is far from perfect itself.
>
> As mentioned previously, the other reason for choosing Sphinx was that
> it is quite extensible.
>
> Ilija

Wouldn't it be simpler and better in the long run to have a separate
Git repository for the PHP language internal documentation? Because
once this will increase in number of files, also php-...tar.gz archive
files will increase and everything will become more complex. It will
also mess the php-src Git log with documentation changes. And the docs
subdirectory in the php-src can be still used for some possible other
files that are needed for the GitHub interface usage. Now we have the
docs-old subdirectory in php-src, which is a bit messy and it might
take a while to migrate all those to RST. It would be also perhaps
smart to sync this initiative with https://github.com/php/php-langspec
somehow or at least to display all of those together in some GH page.

Re: [PHP-DEV] Re: [External] : [PHP-DEV] [VOTE] [RFC] Unbundle ext/imap, ext/pspell, ext/oci8, and ext/PDO_OCI

[Peter Kokot]

On Thu, 2 Nov 2023 at 05:02, Christopher Jones 
wrote:

>
> On 2/11/2023 2:46 am, Derick Rethans wrote:
> > Hi,
> >
> > I have just opened voting on the RFC to unbundle imap, pspell, and
> > oracle integrations.
>
> :)
>
> --
> https://twitter.com/ghrd
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


I'm not sure of all the details but have we missed something with the OCI
extensions? Perhaps some injustice happened here? Probably it would be good
to write something about the OCI extensions before the voting started and
why these shouldn't be unbundled. Reasons in the RFC are quite strong and
it makes the extensions difficult to maintain. Not to mention that
installation on some platforms is not that trivial. That's why I've voted
in favor of unbundling. Otherwise, there are many quite successful PHP
extensions out there that are not part of PHP and are used extensively.
However, for the success Linux packages need to adopt them, so it's
possible to run sudo apt install or sudo dnf install.

Cheers.

Re: [PHP-DEV] Breakages with rc1

[Peter Kokot]

On Tue, 5 Sept 2023 at 11:40, Hanz  wrote:

> Hello,
>
> Ran into a couple of issues with RC1 that I haven't seen online.
>
> With --with-pear: The --with-pear option is deprecated
>
> With --enable-pear: configure: WARNING: unrecognized options: --enable-pear
>
> I'm using --disable-all as the first parameter.
>

There is only --with-pear option and when used it simply emits a warning
since PHP 7.4 to make it clear that in one of the future PHP versions PEAR
won't be installed via PHP build process anymore.

It still works though.

Re: [PHP-DEV] Removing support for the disable_classes INI setting

[Peter Kokot]

On Mon, 14 Aug 2023 at 16:18, G. P. B.  wrote:

> Hello internals,
>
> While working on some DNF type bugs, I discovered some major issues around
> the disable_classes INI setting implementation. Such as:
>
> - A double-free of the type of a typed property
> - A use after free (which segfaults) when trying to access a property
> defined on a disabled class that was extended (e.g. disabling Exception)
> - A use after free when var_dumping a disabled class that has its own
> handler (as it will assume properties to be allocated)
> - And likely more considering the lack of tests surrounding this feature
>
> This feature seems of dubious nature, and the only justification given when
> adding support for this in the changelog of PHP 4.3.2 is:
>
> New "disable_classes" php.ini option to allow administrators to disable
> certain classes for security reasons. [1]
>
> However, only classes defined by extensions can be disabled, and such a
> class is critical for the correct operation of said extension.
> As such, what one should do for security reasons is to not enable the
> extension in the first place.
>
> Moreover, compared to the behaviour of disable_functions which, as of PHP
> 8.0, removes the function declaration completely, disable_classes does not
> remove the declaration of the class, but just "overloads" the object
> creation process to not initialize the object and emit a warning.
> Meaning, it is totally valid to instantiate a disabled class and pass it
> around to functions for them to blow up when they try to use the object as
> intended.
>
> Considering the major flaws in the implementation of said feature, the
> dubious nature of it, and the seeming lack of usage of it (considering none
> of the above breaking bugs have been reported).
> I would like to remove this feature in PHP 8.3, even though I know we are
> past feature freeze and close to the first RC.
>
> I have CCed the RMs for 8.3, and would like the opinion of other people on
> if this removal makes sense to the majority of people
>
> Sincerely,
>
> George P. Banyard
>
> [1] https://externals.io/message/2076


I'm not against removing the disable_classes, but fuzzer SAPI is using this
ini setting like this:
https://github.com/php/php-src/blob/1fe7dc31ef149db20ea3813c92a45deff80c21a3/sapi/fuzzer/fuzzer-sapi.c#L60

>From the user point of view, it would otherwise be good to have a certain
set of PHP functionality that they can always rely on. Checking if some
class or function is disabled in some environment is kind of strange
indeed. But from the PHP configuration point of view, more options to
customize the PHP environment is maybe good to have.

Re: [PHP-DEV] Re: [VOTE] Interface Default Methods

[Peter Kokot]

On Tue, 11 Jul 2023 at 13:37, Levi Morrison  wrote:
>
> On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison  wrote:
> >
> > Chatter on the [Interface Default Methods RFC][1] has been quiet for
> > the past 6 days, and the feature freeze deadline is fast approaching
> > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
> > as usual.
> >
> > Thanks to everyone who discussed weaknesses in the RFC during the
> > discussion phase.
> >
> >   [1]: https://wiki.php.net/rfc/interface-default-methods
>
> The voting period is about half-way through. For your information,
> it's currently sitting at 10 yes and 13 no votes. Thanks to everyone
> who has voted so far.

I really liked this idea actually but I'm still not so sure about it,
what would be the "right" approach. Just one question though. With
this, also the protected methods would be possible to define in the
interface? And what about the properties? Properties would be part of
some other RFC?

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

Re: [PHP-DEV] [VOTE] PHP Technical Committee

[Peter Kokot]

On Fri, 28 Apr 2023 at 12:01, Jakub Zelenka  wrote:
>
> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub

It would be also good to know why people vote no.

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Peter Kokot]

On Wed, 12 Apr 2023 at 15:53, Alex Wells  wrote:
>
> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the best UX out there. Here are
> some immediate flaws which make the process harder than it should be:
>  - having to subscribe to a mailing list to even see the discussions
>  - supporting public archives such as externals.io to expose discussions to
> the public for those who aren't subscribed and keep historical data
>  - having to learn the specific, uncommon rules of replying: bottom
> posting, word wrapping, removing footers. It's not to say any of those
> rules are complex or hard to follow; it's that they're basically
> inapplicable outside of emails, so they're usually not known by newcomers.
> Also popular emailing clients don't do any of that automatically, making
> each reply tedious.
>  - no way of editing a message. Mistakes will always be made, so being able
> to quickly fix them would be nice
>  - no formatting, especially code blocks. Sure, they are possible through
> HTML, but there's no single common way which all of the emailing clients
> will understand - like Markdown
>  - no reactions - it's hard to tell whether something is supported or not.
> This includes both the initiative being discussed and the replies that
> follow. Sure, you can usually kind of judge the general narrative based on
> the replies, but it's not always clear what's in favor. There are usually
> many divergent branches of discussions and it's unknown what's supported
> the most.
>
> Based on those issues and PHP, I propose moving the discussions elsewhere -
> to some kind of modern platform. Since this is quite a big change in the
> processes used, I imagine an RFC would be needed. But before I do that I
> want to measure the reactions. If it goes well, I'll proceed with an RFC
> draft.
>
> There are basically two choices here - a messenger-like platform (i.e.
> Slack, Teams) or a developer focused platform like GitHub. While messengers
> certainly work, they're more focused on working with teammates rather than
> actual discussions. They usually don't have a simple way to navigate
> publicly and are poor at separating multiple topics into threads. Some
> projects use them for that purpose, but it's usually a worse experience
> than what GitHub provides.
>
> GitHub is already used by PHP for both the source code and the issues, so
> that is a good candidate, especially since it's a platform designed to
> handle cases like this. Also, that should be a much easier transition now
> that the source and issues were moved to GitHub.
>
> Also, to be clear: I'm not proposing to remove all PHP mailing lists; some
> of them are one way (i.e. notifications for something) so they should
> definitely stay that way. Some of them might not even be used anymore.
> However, I want this change to affect all two-way (discussion) mailing
> lists if possible. Also, this does not include moving RFCs themselves to
> GitHub, only the discussion that happens via email.
>
> What are your thoughts?

I also prefer mailing lists in addition to 3rd party GitHub
environment. Professional and large open source projects all use such
mailing lists. These mailing lists include two decades of discussions
which is respectable to continue in such direction.

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

Re: [PHP-DEV] LDFLAGS broken?

[Peter Kokot]

On Wed, 22 Feb 2023 at 14:14, Max Kellermann  wrote:
>
> On 2023/02/22 13:45, Max Kellermann  wrote:
> > 13 years ago, there was commit
> > https://github.com/php/php-src/commit/477649cd3f09 which attempted to
> > fix this, but was reverted on the same day by commit
> > https://github.com/php/php-src/commit/16450418b188 with just commit
> > message "Revert bad patch" but nothing else, no explanation what was
> > bad about the patch.
>
> Oh look, there was an "edit war" with a bunch of commits repeatedly
> adding and commenting this "unset LDFLAGS" line:
>
>  https://github.com/php/php-src/commit/c4d84aa33390
>  https://github.com/php/php-src/commit/21a6e1f96229
>  https://github.com/php/php-src/commit/937358ebc7a6
>  https://github.com/php/php-src/commit/477649cd3f09
>  https://github.com/php/php-src/commit/16450418b188
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

>From my quick check, the unset is initially done to move the currently
set flags to extra flags variable and clean the variable for further
additions so there are no duplicate ones or something like that.
https://github.com/php/php-src/commit/9417570dc1f31a0e3ddb9f6736a547c87ce7cfba

There seems to be another unset done to this change here:
https://github.com/php/php-src/commit/c4d84aa33390045cd4ff542719a0f79cff52fb7c
which fixed some bugs related to linker errors and duplicate symbols.
https://bugs.php.net/bug.php?id=14616
https://bugs.php.net/bug.php?id=14824

Most likely, some of those three unset lines could be removed today,
yes, but I can't be sure. If removal would fix some bug, then probably
it is time to remove them and see where things break afterwards.

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

Re: [PHP-DEV] [VOTE] include cleanup

[Peter Kokot]

On Sun, 12 Feb 2023 at 09:31, Max Kellermann  wrote:
>
> On 2023/02/11 17:14, Peter Kokot  wrote:
> > I've voted in favor of the RFC because of the code-cleaning,
> > tech-debt-reducing improvements to code readability.
>
> Exactly my point, and I'm surprised by the resistance.
>
> Not only surprised, but also disappointed that many have voted against
> code cleanup, but where have those people been when this was being
> discussed?
>
> Matthew said there had been "chatter from a number of folks after the
> changes were merged about builds no longer compiling", but was not
> able to render that more precisely.
>
> None of that was discussed on GitHub nor here on php-internals.  I
> have to question whether these build breakages even exist.
>
> (Other than the DTrace build failure which happened because one line
> was missing, but that's a fact and not "chatter", and one bug reporter
> and not "a number of folks".  Let's put this dead horse to rest.)
>
>
> > BTW, merging from PHP 8.1 up is not problematic. Git diff only looks
> > at a few lines of code above and below. Not the top of the file.
>
> This was the only counter-argument ever discussed here, and I'm
> puzzled that the imagination of merge conflicts scares so many people.
> About a kind of change that is unlikely to cause one.
>
> Any code change can cause a merge conflict, but include cleanups are
> the least likely cause of all, because include directives are almost
> never touched in bugfix-only branches.
>
>
> Is that all, or is there another, yet unnamed reason why there's so
> much resistance?  The hearsay about build failures?
>
>
> There are 3 more days to vote, and it's a tie currently - means 9
> "YES" votes missing for supermajority or else the RFC gets rejected.
> That rejection would not only be a missed chance to modernize the PHP
> code base, but also a sign to potential PHP contributors that the PHP
> maintainers don't value clean code.  This is unsettling.
>
> Imagine how this will overshadow future attempts to remove historical
> cruft from a decades-old code base, because the counter-arguments
> apply the same to any kind of code cleanup.  As any decades-old code
> base, there's a lot of historical cruft in PHP which gets in the way
> all the time, much more than a hypothetical one-time merge conflict.
> Historical cruft keeps piling up if you don't keep cutting it down all
> the time.
>
> Cleaner code is easier to read and understand, which makes existing
> bugs easier to fix and makes new bugs less likely to be added.  That
> outweighs, in my opinion, all the possible disadvantages that the
> process of code cleanup could possibly have, by orders of magnitude.
>
> Max

Well, the PHP long-term maintainers are just a bit stubborn when it
comes to such changes and probably what concerns them is writing code
styles in stone. We shouldn't conclude that the PHP team as a whole
doesn't care about clean code based on this voting. People just need a
bit of time to grasp the changes and discuss these things over a
longer period. They just care more about the stability of the current
repo and the extensions out there than the cosmetics of the ASCII
characters in files. I agree though, that both sides need to be
improved.

One more question here. Is the iwyu (include-what-you-use) tool used
here to clean up these header files?

I'm assuming something like this could be one day executed:
iwyu --no_fwd_decls --no-comments

Based on this, this is an awesome tool and can improve the code.

I'd say to go hand in hand here and one day later discuss things like
this again to integrate these gradually. Automating is always tricky
on the other hand. Like adding the iwyu step in the build checks.

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

Re: [PHP-DEV] [VOTE] include cleanup

[Peter Kokot]

On Wed, 1 Feb 2023 at 13:14, Max Kellermann  wrote:
>
> On 2023/01/30 11:26, Max Kellermann  wrote:
> > If nobody objects, I'll announce the start of voting on February 1st.
>
> That's today.
>
> Voting starts now, please vote on my RFC:
>  https://wiki.php.net/rfc/include_cleanup
>
> Original discussion: https://news-web.php.net/php.internals/119272
>
> [Reposting this to create a new thread; thanks Tim for the hint.]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


Hello,

I've voted in favor of the RFC because of the code-cleaning,
tech-debt-reducing improvements to code readability.

Additionally, PHP-SRC should adopt some suitable Clang-format rules
and gradually integrate them into the code.

BTW, merging from PHP 8.1 up is not problematic. Git diff only looks
at a few lines of code above and below. Not the top of the file.

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

Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte

[Peter Kokot]

On Sat, 10 Sept 2022 at 11:32, Yasuo Ohgaki  wrote:
>
> 2022年9月7日(水) 22:58 Misha :
>
> > Hello everyone,
> >
> > We spend a lot of time to increase limits for uploads file in PHP. Can we
> > increase it in php.ini?
> >
> > Current value is 2Mb. Its so small value, when photo image can take 8Mb on
> > iPhone X.
> > We should increase it to 50Mb, because DevOps engineers do useless work
> > trying to change it.
> >
> > I have prepared PR for it https://github.com/php/php-src/pull/9315
> >
> > Take a look and approve it please.
> >
> > Thanks!
> >
> > --
> > Best regards, Michail
> >
>
>
> I can understand the motivation, but I am against the change.
>
> To increase uploaded file max size, POST max size must be increased too.
> For 99.99% entry points do not need 50MB POST max size.
> and larger POST max size increases DoS risks.
>
> Default upload file max size and POST max size should be small enough value
> for better security.
> IMHO, PHP script that handles large POST data should increase these
> settings.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

If I'm not mistaken, even the memory_limit needs to be increased when
the post_max_size directive is larger. The memory_limit needs to be
larger than post_max_size. And the post_max_size must be slightly
larger than upload_max_size.

memory_limit > post_max_size > upload_max_size

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

Re: [PHP-DEV] Re: Adding new closing tag =?> for keeping trailing newline

[Peter Kokot]

On Wed, 8 Jun 2022 at 20:16, shinji igarashi  wrote:

> > declare(ignore_newline_after_close_tag=false);
>
> Thanks for coming up with another idea!
>
> As others have already pointed out, disabling the closing tag from
> eating trailing newline throughout the file would be inconvenient if
> we want to use control statements in the template.
>
> However, we currently only have one closing tag, but we already
> have two opening tags. So, for example, if we use declare to disable
> the newline eating only when closing a PHP block started with ` it can produce the desired output.
>
> 
> 
> - 
> 
>
> I'm honestly not sure if adding a declare switch is better received
> than a new closing tag, though.
>
> Thanks!
>
> --
> Shinji Igarashi
>
> 2022年6月8日(水) 12:34 Sara Golemon :
> >
> > On Tue, Jun 7, 2022 at 10:27 AM Robert Landers 
> wrote:
> > > FWIW, I think it makes a lot of sense, having used golang's template
> > > language (not everyone is generating HTML with PHP). I think you may
> > > just be dealing with a vocal minority and it would be worth putting to
> > > an actual vote. Even if it fails, we'll learn something the next time
> > > someone wants to change something like this.
> > >
> >
> > While my gut response for the new end tag is in the "no" column, I do
> wonder if we can accommodate "non-html" scenarios in a broader (maybe more
> palatable?) way by assuming that if you want the newline to be respected on
> one line, you probably want it that way for the whole file.
> >
> >  > declare(ignore_newline_after_close_tag=false); // defaults to true, i.e
> existing behavior
> >
> > This would avoid any new syntax rules, but still provide the ability for
> php-as-template-engine to behave in the user's preferred mode.
> >
> > -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


I'm just adding a few cents into this discussion for some inspiration. If
I'm not mistaken, the Twig template engine, for example, has such a
difference integrated in the output tag and the statement tag. The
statement tag ({% %}) behaves as PHP tag, it removes the newline character.
The outputting tag ({{ }}) adds a newline at the end.

See this: https://twigfiddle.com/pto9qx

More info about this here:
https://twig.symfony.com/doc/3.x/templates.html#whitespace-control

So, it is actually important to have such functionality in templates.

Re: [PHP-DEV] [VOTE] Fibers

[Peter Kokot]

On Mon, 22 Mar 2021 at 18:23, Guilliam Xavier  wrote:
>
> On Mon, Mar 22, 2021 at 5:23 PM G. P. B.  wrote:
>
> >
> > The thing is that by my recollections votes have already been extended.
> > Mostly when there has been issues with the mailing list, or some outside
> > event.
> >
> > Moreso, I don't think extending a vote will in most cases result in the
> > outcome
> > they want (acceptance), but I might be mistaken. In this case however it
> > is a
> > bit meaningless as it's already passing.
> > So I think if there needs to be a discussion about clarifying the voting
> > RFC
> > document it should be made in a different thread.
> >
> > Best regards,
> >
> > George P. Banyard
> >
>
> You're right.  Sorry, I didn't intend to start a debate (nor to be rude to
> Levi), just being probably overly cautious ("better safe than sorry", I
> remembered that some people challenged the validity of votes on the basis
> of "bureaucratic" arguments in the past, and wanted to avoid that here)...
> (In this case I personally find it reasonable, but who am I?)
>
> Just in case, let's record that the result is currently 48:14 ;)
>
> --
> Guilliam Xavier

+1 for extending the voting phase for a week. World will not end. If
anything, everyone will be more confident that the RFC voting results
were the correct choice for further development of async PHP. Even if
one week more would change the voting results, then extending the
voting was a correct choice.

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

Re: [PHP-DEV] [VOTE] Fibers

[Peter Kokot]

 Hello everyone,

I'm just adding a few cents into this discussion.

I've voted "yes" because we don't have any other async stuff RFCs available
nor in the preparation. PHP needs such functionalities very badly and very
quickly to sort of speak. Adding a brand new extension in the core is maybe
a strange practice because it usually should go into PECL first and after
being adopted by the ecosystem it could be then moved to php-src after a
vote. However, practical reasons show that PECL extensions are not first
class citizens. In most cases adopting extensions could take even longer.
With somehow similar logic, I've also supported FFI extension and even Jit
RFCs already in 7.4.

Regarding Swoole, Swoole is a great production-ready framework that
provides such functionality also already today. It is definitely worth
checking out from a user perspective and can live along the ext-fiber just
fine, I believe. If Swoole won't be integrated in core (it is a separate
standalone project), then hopefully, PHP core could learn and be inspired
by Swoole as it's already implemented in production with unbeatable
performance.

Thank you to the RFC authors and everyone involved in making this happen.

Re: [PHP-DEV] MODERATE spam

[Peter Kokot]

Hello,

On Thu, 5 Sep 2019 at 03:45, Sascha Schumann
 wrote:
>
> Looking good (test 3).
>
> Please alert syst...@php.net if you have issues sending emails to 
> *@lists.php.net.
>
> Sascha
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Confirming that most spam got nicely reduced now. Thank you for
enabling spam filters. There are now only few of those spam mails
passing through but I guess reading one or two messages with pharmacy
and similar content can be ignored and deleted on the mods side.

> Who can we add as moderators?

Oh, another thing. Increasing number of moderators here (on mailing
lists) doesn't help in any way. Still each moderator has the same
amount of emails to go through and the work load is not distributed
but duplicated. If we all understand this. But hopefully the relevant
emails could be approved on time anyhow.

Cheers.
-- 
Peter Kokot

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

Re: [PHP-DEV] Changing fundamental language behaviors

[Peter Kokot]

> do it from a human perspective.
>
> Zeev
>
>
> >

Just a dumb idea, since there clearly is a majority in favor of the
change with these warnings and strictness and all that now... Why not
making something like an LTS PHP 7.x where all the legacy code would
work OK as long as practically possible and 8.x+ would be the future
of what the developers want and not what business wants? One who won't
upgrade due to the BC breaks also won't need the new features anyway
very realistically.

Microsoft, Zend, and Red Hat have been showing that this is actually
possible. How smart this is for the PHP progress is another story, but
for the business it might be good to think about this also I guess:
https://github.com/microsoft/php-src/releases

So, to make some sort of a milestone with some of the versions -
either 8 or 9 or something.


-- 
Peter Kokot

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

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

[Peter Kokot]

On Fri, 6 Sep 2019 at 11:11, Rowan Tommins  wrote:
>
> On Thu, 5 Sep 2019 at 22:45, Peter Kokot  wrote:
>
> > GitHub usage is inevitable.
>
>
>
> Did you use the wrong word here, or are you saying that, of all the
> hundreds of different platforms we could investigate, there is no chance
> that we would end up using something other than github?

Plastic analogy - adding "127.0.0.1 github.com" to your /etc/hosts
file shows that developer cannot bring most of the today's (PHP)
projects to any working state without using it. That's what is meant
by inevitable because everything open source today is either on GitHub
and some minor ones scattered around custom Git repos and other Git
hosting providers. PHP is already using GitHub. Is it moving to
something else? No, so let's not complicate things more with other
hosting providers now.

USA political issues and embargo on some countries are indeed a reason
I'm also willing to accept that PHP won't be using GitHub otherwise.
For other reasons presented here, none is  convincing enough to me
honestly.


-- 
Peter Kokot

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

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

[Peter Kokot]

Hello,

On Thu, 5 Sep 2019 at 12:22, Côme Chilliet  wrote:
>
> Le jeudi 5 septembre 2019, 12:04:55 CEST Brent a écrit :
> > > Huge "no" from me on using github for discussing RFCs.
> >
> > Care to elaborate why? The majority seems to like it. Though I am also 
> > curious about Nikita's experience with it, as he is the one having to 
> > process the feedback.
>
> Because the PHP project should avoid depending on a privately owned 
> centralized service for its technical discussions, and should not encourage 
> (some would say force) people to use such platforms.
>
> PHP is already on github but it’s only a mirror, the main git repository is 
> at git.php.net .
>
> Côme

If I may put few random thoughts here. GitHub usage is inevitable. The
interface is so good with clear discussion and review options that it
would be really worthy to check it out for all PHP RFCS in the future.
The main worry here is basically that one day GitHub will go offline
and that discussion will be lost. Repository however will stay in the
Git repo and will be "timeless". Very rarely one will want to look at
the old (several 10 years) discussion comments. This is not a problem
because even with having an email archive online very rarely someone
will return to such discussion. RFC content is there and will be there
for PHP to move "elsewhere" though if such hypothetical case comes.

Tank you.


-- 
Peter Kokot

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

Re: [PHP-DEV] Make error_reporting=E_ALL the default

[Peter Kokot]

Hello,

On Fri, 30 Aug 2019 at 13:51, G. P. B.  wrote:
>
> On Fri, 30 Aug 2019 at 11:45, Zeev Suraski  wrote:
>
> >
> > > On 30 Aug 2019, at 12:33, Nikita Popov  wrote:
> > >
> > > Hi internals,
> > >
> > > Relating to the recent discussions on undefined variables & co. One thing
> > > that is particularly annoying about the undefined variable case is that
> > our
> > > default error_reporting level (without a php.ini) does not include
> > E_NOTICE.
> > >
> > > Thankfully distros do tend to have more reasonable defaults, but if you
> > > spend as much time with custom PHP builds as I do, not seeing *anything*
> > > for undefined variables is a pretty big annoyance.
> > >
> > > Does anyone see an issue with making error_reporting=E_ALL the default in
> > > PHP 8? It can of course still be manually downgraded via php.ini and
> > > php.ini-production will retain the existing recommendation that excludes
> > > E_DEPRECATED/E_STRICT.
> > >
> > > PR: https://github.com/php/php-src/pull/4659
> >
> > By the way - I'd consider going a bit further than that, and re-sync our
> > internal defaults with the values of php.ini-development.  In the past -
> > when we had -dist and -recommended - the intended behavior was that having
> > php.ini-dist as your php.ini would be identical to not having a php.ini
> > file at all.  I think it can be useful if we do the same for
> > php.ini-development (by changing the internal defaults to correspond to it
> > of course, not the other way around) instead of having to agree
> > individually on each change.  For the future, agreeing on a change in
> > php.ini-development would directly imply changing the internal defaults.
> >
> > Zeev
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> I'm not sure we can totally execute on that otherwise we would need to
> change the default of the short_tag directive, which from my understanding
> was one of the pain points of the Short Tag RFC.
> Other than that I wholeheartedly agree that syncing the dev one with the
> defaults would be a good idea but then I'm not totally sure what it's point
> *would* be.
>
> Best regards
>
> George P. Banyard

About the error_reporting, I always set this to E_ALL for all
environments also, yes.

Syncing with the php.ini-production would probably make more sense
because there are production environments that might not use any ini
files (a bit of an edge case but when developing adding ini file seems
more natural and secure than the other way around I think). The short
opening tags ini directive of course will now stay different than the
PHP internal default.
-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 23:37, Rowan Tommins  wrote:
>
> On 20/08/2019 22:18, Peter Kokot wrote:
> >> The approach was: add the deprecation notice in PHP 8, and remove short 
> >> open tags in PHP 9 or PHP 10 (purposely left vague to get more support for 
> >> the idea - as getting the deprecation underway is the most important move).
> >>
> > I guess we should really highlight also
> > such option and discuss this more rationally back then. Now, we have
> > postponed this until who knows when and also without any clear
> > guideline for what will happen with short tags if they will be ever
> > removed or not...
>
>
> I honestly don't think it would make any difference to most people who
> voted against. The counter-arguments people have presented, again and
> again, are not about the pace of removal, but about whether removal is
> needed at all. If anyone wants to revive this proposal in future, it is
> that counter-argument that they would need to understand and address.
>
> Regards,

I think so too, yes. We will have the same discussion... I'll leave it
be. I just have my own opinion about them. Facts are facts (what
software does and allows to do) and what documentation and code
comments say (something completely different). What is programmer
advised to do is not the same as what can programmer do with the
language. That's all.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 19:47, Peter Bowyer  wrote:
>
> On Tue, 20 Aug 2019 at 17:18, Peter Kokot  wrote:
>>
>> Let's simplify this a bit because I'm not sure I have seen anyone
>> mentioning something like a PHP 10 milestone in all these discussions.
>> If we want to get rid of some feature like this a very long timeline
>> needs to be done and also major versions needs to be taken into
>> consideration.
>
>
> It does indeed, and this approach was proposed by myself and another person.
>
> The approach was: add the deprecation notice in PHP 8, and remove short open 
> tags in PHP 9 or PHP 10 (purposely left vague to get more support for the 
> idea - as getting the deprecation underway is the most important move).
>
> It met with deafening silence.
>
> Peter

Then I apologize if your suggestion has been missed to do that like
this (there were too many emails stuck in loops and probably time
period of 5 to 10 years in the future is a bit problematic to
understand, and last but not least a bit of an issue when there is a
very clear feedback from people present since day 1 where they
recommend something else). I guess we should really highlight also
such option and discuss this more rationally back then. Now, we have
postponed this until who knows when and also without any clear
guideline for what will happen with short tags if they will be ever
removed or not...

--
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 18:39, Rowan Tommins  wrote:
>
> On 20/08/2019 17:18, Peter Kokot wrote:
> > About the docs - there are
> > very minor changes needed where "backwards compatibility" is mentioned
> > maybe. Because they are not in PHP for keeping BC anymore now. Nobody
> > proposed a better solution than this RFC, then they are a feature.
>
>
> Being "for Backwards Compatibility" and being "there forever" are not
> mutually exclusive. There are a huge number of things in this world
> which exist only to be compatible with an older technology or use case,
> but which will never be phased out, because the effort to change them
> exceeds the benefit.
>
> On the other hand, I think it might be useful to have a status of
> "officially discouraged" distinct from "deprecated". I occasionally hear
> people ask to "deprecate" something without any particular timeline or
> criteria for when it would be removed; my suspicion is that what they
> really want is a clearer message to users that they shouldn't use the
> feature.
>
> Regards,

Probably. But fact is that PHP opening short tags can be used. We can
enable them in controlled environments and use the short tags knowing
they will never be removed now. No deprecation warning is standing in
our way to do that now. And such code (or better put app) is honestly
now also not so bad. Because it will still work in at least let's say,
PHP 9 at least or considering the feedback and discussions for ever...
Also users who are already using short tags can now postpone the
upgrades for another ~5+ years at least :)

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 18:02, Chase Peeler  wrote:
>
> On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot  wrote:
>
> > On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
> > >
> > > Hello internals,
> > >
> > > This RFC has been declined with 56% in favour (30/54) and 44% against
> > > (24/54).
> > >
> > > Two side notes to this:
> > >
> > >   - I seriously don't appreciate that the RFC has been edited *WITHOUT*
> > my
> > > knowledge to add endorsement names on the counterargument to the RFC on
> > the
> > > RFC itself  when the appropriate place would have been the counter
> > argument
> > > document.
> > >   - As it has no clear supra majority (nor against nor in favour), this
> > > topic should probably be put to discussion again in some way or form at a
> > > later stage.
> > >
> > > Best regards
> > >
> > > George P. Banyard
> >
> > The number of things that got wrong in these two RFCs is
> > extraordinary.
>
> What was done incorrectly in regards to the second RFC?
>
>
> > If anything the community, the internals and everyone
> > involved got through a good thinking process so we have learned
> > something from this in any way. I appreciate all your time and effort
> > to move this thing forward and even for being so respectful towards
> > Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
> > PHP and to repeat the voting with a better solution in this RFC.
> >
> > You say that like being respectful to people with opinion different than
> yours is something worth commending, when it should be the default
> behavior. In other words, you are implying that anyone that opposed this
> RFC didn't deserve respect, so, congratulations to everyone for showing it
> anyway.
>
>
> > I think that now we need to fix the documentations out there. short
> > tags will stay in PHP for at least another 10+ years, so maybe we
> > should simply consider them not a part of legacy but a special kind of
> > a feature. There are some parts in PHP comments and docs that needs
> > this fixed and sorted out better a bit (probably - specially in the
> > ini files itself etc).
> >
> > I think we should still discourage their use. We should be explicit in the
> documentation that code which uses short tags might not be portable. Just
> because they exist, doesn't mean we should suddenly change our treatment of
> them when it comes to best practices. If there is any documentation that
> doesn't make this clear, submit a bug report.
>
> If you really feel that we should start treating short tags as totally
> legitimate, then someone else with better knowledge of how to proceed with
> that will need to provide advice.
>

Let's simplify this a bit because I'm not sure I have seen anyone
mentioning something like a PHP 10 milestone in all these discussions.
If we want to get rid of some feature like this a very long timeline
needs to be done and also major versions needs to be taken into
consideration. And from all the discussions I got a feeling that not
everyone who voted "No" (who want the short tags in PHP) also want to
get rid of them. Ever. So that's why. We can live with short tags in
PHP as a feature. And so can legacy projects be upgraded to not use
them anymore so nothing to worry too much I think anymore now. We'll
discuss this maybe in 5 or 10 years then. About the docs - there are
very minor changes needed where "backwards compatibility" is mentioned
maybe. Because they are not in PHP for keeping BC anymore now. Nobody
proposed a better solution than this RFC, then they are a feature.
Cheers.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
>
> Hello internals,
>
> This RFC has been declined with 56% in favour (30/54) and 44% against
> (24/54).
>
> Two side notes to this:
>
>   - I seriously don't appreciate that the RFC has been edited *WITHOUT* my
> knowledge to add endorsement names on the counterargument to the RFC on the
> RFC itself  when the appropriate place would have been the counter argument
> document.
>   - As it has no clear supra majority (nor against nor in favour), this
> topic should probably be put to discussion again in some way or form at a
> later stage.
>
> Best regards
>
> George P. Banyard

The number of things that got wrong in these two RFCs is
extraordinary. If anything the community, the internals and everyone
involved got through a good thinking process so we have learned
something from this in any way. I appreciate all your time and effort
to move this thing forward and even for being so respectful towards
Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
PHP and to repeat the voting with a better solution in this RFC.

I think that now we need to fix the documentations out there. short
tags will stay in PHP for at least another 10+ years, so maybe we
should simply consider them not a part of legacy but a special kind of
a feature. There are some parts in PHP comments and docs that needs
this fixed and sorted out better a bit (probably - specially in the
ini files itself etc).

-- 
Peter Kokot

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

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

[Peter Kokot]

On Mon, 19 Aug 2019 at 01:06, G. P. B.  wrote:
>
> Hello internal,
>
> It seems this topic already has been raised a year ago [1] but nothing has
> been done.
> So I would like to raise the issue again, there are a various of old and
> empty branches currently in git, would it be possible to remove them?
>
> Best regards
>
> George P. Banyard
>
> [1] https://externals.io/message/102982

Hello,

Consistency, cleanliness, good organizational things are a virtue. It
is not an OCD thingy as some might present it. It is an essential part
of good organization. Even with a list of branches that someone with
access might even mistakenly pushed to origin decades ago.

-- 
Peter Kokot

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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Peter Kokot]

Hello,

On Wed, 14 Aug 2019 at 17:14, Derick Rethans  wrote:
>
> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this. Hence, I've created a document in the wiki as a poll:
>
> https://wiki.php.net/rfc/p-plus-plus

Off topic question/request if it's maybe possible and doable unless
I've missed something. Current RFC process is in short something like
writing a text document together with the implementation itself via a
pull request already and at the same time the discussion phase is
happening. After discussion there is a voting phase based on the
feedback from the comments. There, many times people who vote also
sometimes don't add reasons why they vote against something and they
stop the RFC from passing. RFC author, not only cannot implement it
but they also waste their time with the implementation.

Would it be a good thing if the RFC author would have a similar option
to get voting results feedback before starting to code (implementation
phase) on the RFC? So, they can see the results before the voting
phase and if the time investment is worth the trouble of adding a
feature or not.

Thank you.
-- 
Peter Kokot

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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Peter Kokot]

On Wed, 14 Aug 2019 at 22:41, Zeev Suraski  wrote:
>
> On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans  wrote:
>
> > Hi,
> >
> > In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> > Before we end up spending this project's time and energy to explore this
> > idea further, I thought it'd be wise to see if there is enough animo for
> > this. Hence, I've created a document in the wiki as a poll:
> >
>
> All,
>
> Using a humoristic tone, I'm happy that finally internals@ is so unified.
> I almost get the feeling that you may not like the idea...
>
> On a more serious note, I'll keep the feedback on the validity of this vote
> in just about every aspect (process, jurisdiction, anything really) to
> myself, and say just two things:
>
> - The P++ idea makes absolutely no sense in vacuum.  The reception around
> this idea implied a decision between 'one big happy family' and 'a split'.
> Since at this stage these are the perceived choices - I'd vote against it
> too (which I just did, why not).  However, I believe it's a false choice.
>
> - It will absolutely make sense to discuss it when it'll start becoming
> clearer to everyone that 'one big happy family' is really not an option.
> We'd be choosing how to soft split the family - granularly (2^n dialects),
> into many editions (n dialects), or into two separate dialects with clearer
> mandates (2 dialects).  I get it that it's intangible for many of us
> (myself included, to a degree), which is why this idea is perceived as the
> 'evil splitter' for everyone to unite and rally against.  Maybe I'm wrong,
> and the changes/features that I think are about to make it into PHP aren't
> going to require any sort of split.  If that's the case - it's indeed a
> horrible idea.  We'd only be able to see that a but further down the road.
> It's definitely too early to spend that level of energy on it at this stage
> - but at the same time, it will definitely make sense to explore it if &
> when the reality I think we're going to be facing would begin to unfold.
>
> I will not be responding to any further emails on this thread;  I'll
> happily reply to private messages though.
>
> Thanks,
>
> Zeev

Hello @everyone,

this then also means that PHP will now never be a consistent language
and short tags will be forever in so we will all be able to support
Chase's gigantic legacy project forever?

Solution would be if we can make this issue that was mentioned:
- elephpant vs elep++ant

into a similar issue as is now:
- elephpant vs elephpantwithstricttypes
(non existent issue - all part of the one PHP itself)


--
Peter Kokot

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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 14 Aug 2019, 12:09 Reinis Rozitis,  wrote:

> > It is surprising how thing that is considered by one to be a security
> risk, is treated
> > as nothing relevant by others. This dichotomy is quite disturbing - in
> what case
> > removing security risk is "no real gain"?
>
> It's questionable that a misconfigured environment is a "security" risk
> caused by language rather than ignorance of the administrator.
>
> On that matter you could ask why are all the exec/passthru/proc_open etc
> functions/features are allowed by default while every other guide on
> hardening web suggests those to be disabled (added to disable_functions)?
> I would bet there have been a lot more (actual) security breaches because
> of unsanitized/unescaped parameters to those.
>
> Just to repeat some other people - there are a lot other things to work on
> than this.
>
> rr
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Appologies if these short tags are bumped so many times and cause so much
issues but we are at the very starting discussions of PHP 8 also. Major
version, where breaking thing was supposed to be possible. So that is one
of the reasons why this and similar cleanups are mentioned in the first
place. With closing the door to even talk and work on cleanups, or being
ashamed of it, or bully others because they want to have a better structure
with using PHP 8+, nothing good can come out of it.

>
>
>

Re: [PHP-DEV] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 14 Aug 2019 at 11:09, Christian Schneider  wrote:
>
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
> >> The best counterargument I can give against "cleaning up" is that it takes 
> >> energy away from actual new features, even if it's just the mental energy 
> >> of monitoring and responding to long threads like this one.
> >
> > Code is like a garden. If there are unwanted weeds and nobody cleans
> > them up, the flowers don't shine and grow as they should.  Cleaning of
> > the weeds is just as important as new features. A bit less but
> > important.
>
> Going with your analogy: Some things (like short open tags) are that 
> individual small flower in the corner of the garden which does not multiply. 
> We already spent way too much time discussing it, the rest of the garden 
> needs water and the gardeners are fighting over a dandelion. A bike-shed 
> discussion at its worst: No real gain but everybody has an opinion.
> Real cleaning up, now that's where it gets interesting. And those discussions 
> tend to be more productive even recently.
>
> Oh and: I'm very much afraid the OP was trolling and succeeded in getting 
> people to react, so please, please let this particular thread die :-(
>
> - Chris

I'm sorry but until the RFC is still in voting phase, participants
should be welcome to express opinions. And the message by OP was
correct. PHP is having a lot of these old sins and they are standing
out, yes.


-- 
Peter Kokot

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

Re: [PHP-DEV] Re: Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 14 Aug 2019 at 10:11, Rowan Collins  wrote:
>
> On 13 August 2019 19:19:42 BST, Olumide Samson  wrote:
> >Not sure what the counter argument is really driving at.
> >So, because some people are using a function or an unworthy directive,
> >then
> >there can't be a major change in that aspect?
>
>
> That's not what anyone is saying. What people are saying is that we shouldn't 
> just make changes because we feel like it; there should be a strong reason 
> for the change. Most people probably even agree up to that point, but 
> disagree with whether the reasons given for this particular case are strong 
> enough.
>
>
> >Not sure where this project is headed, some will want a code to stay
> >because they want easy version upgrade(must everyone upgrade? ) and
> >those
> >who want to shake things up won't be allowed to do so.
>
>
> I find it really frustrating that this feature, that most people had probably 
> forgotten even existed, has somehow been taken as an example of the pressing 
> need for change.
>
> If you propose something that will actually take the language forward, but 
> needs to break a few things along the way, then you might have a valid 
> complaint about lack of vision. But there is no feature which will be 
> unlocked by removing short tags; no big selling point we can talk about at 
> conferences; it will either work, or it won't, and most people's code will 
> not be affected one way or the other.
>
> Most people's wishlists for PHP, even some of the posts in this thread, 
> include things like generics, union types, enums, CoW classes/structs, 
> annotations. To my knowledge, none of those is currently being blocked by the 
> need for backwards compatibility; most are being blocked because they're hard 
> to design, and hard to implement.
>
> The best counterargument I can give against "cleaning up" is that it takes 
> energy away from actual new features, even if it's just the mental energy of 
> monitoring and responding to long threads like this one.
>
> Regards,

Code is like a garden. If there are unwanted weeds and nobody cleans
them up, the flowers don't shine and grow as they should.  Cleaning of
the weeds is just as important as new features. A bit less but
important.


-- 
Peter Kokot

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

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

[Peter Kokot]

me will simply know how
> to run in two different modes - depending on the file at hand - similarly
> to how we do strict types (and we could probably entertain other options as
> well, like doing it on a namespace level).
>
> I want to illustrate what I think this will buy us, at least from my POV.
>
> In P++ (temp code name) - we'd be able to get rid of elements that have
> little going for them other than backwards compatibility - such as short
> tags (not sure about hebrev :)).
>
> But more importantly - we could make much more radical changes a lot more
> quickly.  Since migration would be opt-in - we won't have to worry about
> breaking people's code, and will be able to (and probably should) introduce
> all of these things overnight, so that they're a part of a consistent new
> paradigm and not a slow steady stream of breakage.  We could (and probably
> should) make it strict from the get go - and not just with types - but also
> with ops, variable declarations, etc.  We could change array behavior to
> differentiate between integers and integer-looking-numbers.  And probably
> quite a few other things that currently bother some of us.  And we could do
> all that without sacrificing compatibility.
>
> There's another advantage to doing that - it will allow us to rebrand.
> It's no secret that PHP has a negative reputation among many developers.
> Without getting into the question of whether it's justified or not -
> starting with something that's a lot closer to a clean slate - and under a
> different name - can make a much bigger impact than slow, gradual evolution
> under the same name (which, as I've been working hard to illustrate for a
> long time, also has substantial downsides).
>
> Now, the PHP (old/current) flavor won’t stagnate either - it will still
> benefit from evolution in extensions, other evolving pieces (like JIT or
> other improvements in the runtime) and security updates.  Things which
> those who care primarily about keeping their code working, or that don’t
> care for an ever evolving stricter language (and there’s many of them) -
> will be able to continue enjoying.
>
> I admit, I haven't thought about every possible corner case we may have
> here, and it's still very raw.  But at a high level, it seems to make a lot
> of sense to me, and I think the advantages of going in this direction -
> both technology related, and in restoring calm (and perhaps even renewing
> enthusiasm) around internals@ - are strong enough for us to brainstorm
> about it.
>
> Thoughts?
>
> Zeev

>From my understanding the core thought and philosophy here is very
great. Also thank you that we even have such discussion. It shows that
PHP cares for future changes after all. Maybe instead of making two
languages there probably is also some kind of other middle way (like
it was mentioned in one of your emails in the past I think a bit):
Something such as "legacy" extension (or better named to not cause
issues with meaning that something like short tags will go away in
future - the "traditional" extension) or something like that.
Where developer would have option to enable it and use "traditional"
or whatever named PHP functionalities such as short tags and things
that cause so many issues and being sidelines. Without enabling (or
importing that), PHP would behave more futuristic oriented.

There will still be a need to take compromises in either case. Even in
the PHP vs PHP++ case where people will want to change something in
the PHP or do differently in PHP++. That's quite normal. Important
thing is that everyone has a bit of an overview of everyone else also.
One camp that recommends going without short tags and the other that
wants these in, as an example.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

where the existence of short tags hurt them,
> or, the continued existence is likely to have a large negative impact on
> them in the future.
>
>
> > Zeev
> >
>
>
> --
> Chase Peeler
> chasepee...@gmail.com

Thanks for sharing your stories about issues. Maybe we should start
also thinking about the impact on the language attractiveness to pick
it when starting a new web project since the core people can't come to
conclusions how to make the language more consistent on the long run
(PHP 9 etc)... With more and more ambiguities, inconsistencies,
lockups, and dead ends behind the language there is probably also a
bit of a factor to consider that it lowers this attractiveness.
Meaning less people will think of adopting it (with all the things
combined - short tags, that and that inconsistency not being removed
from PHP due to major disastrous BC break there and there). So, the
damage is also on the long run with more and more locks and dead ends
not being able to be fixed and cleaned.


-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Thu, 8 Aug 2019 at 00:38, Zeev Suraski  wrote:
>
>
>
> On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot  wrote:
>>
>> Thank you for such a detailed response. Ok, I understand then. Then
>> next logical step here is - I would maybe want to use these awesome
>> short tags also then.
>
>
> No disrespect Peter, but I really don't think you understand (my position).
>
> I don't think there's anything awesome about short tags.  I don't think 
> there's anything evil about them either.  They are what they are, what they 
> have been for the last two decades.  They didn't cause any damage to PHP, and 
> they won't start causing damage to PHP in the future.
> Personally, I like the verbose version a lot more, I like the verbosity.  I'm 
> capable of holding that preference in my mind alongside realizing that others 
> have a different preference.  I'm not missionary about my tag preferences, 
> and neither should you.
>
>
>> So, why not enabling these short tags everywhere then and suggesting
>> in the PHP manual that they can be used again in PHP x.y version etc?
>
>
> As much as it's an uncommon use case - I think making PHP inherently 
> incompatible with XML is not a good idea.  As I mentioned, personally I also 
> prefer the verbosity as well as the free PHP publicity in every tag.
>
> But a more fundamental level, I really fail to see any good reason to be 
> spending our brain cycles on this matter (yes, I realize that we're waaay too 
> late, but better late than never).
> This is a non-issue, that we suddenly made into an issue, and now we need to 
> discuss it, come up with pros and cons, debate them, write lengthy proposals 
> and counterarguments - and for what?  For dealing with a non-issue.
> Can we turn this issue back into the non-issue that it is?
>
> Zeev

I can do that. I just wanted to get some more possible explanations,
because there isn't any guideline why these tags are (still) in PHP
and why someone would want to use them (because this is the case
actually). Now, I think we all understand better here. No. 1 reason
they are (still) there is the legacy code support - understandable.
They in its core essence shouldn't be used and are discouraged further
on as manual suggests. Many languages would make these "obsolete"
somehow (probably) I think but ok if they are meant to be in, so be
it...

And maybe also for the community out there to understand this entire
issue better and the outcome of the RFC whatever it is when voting
ends.

Have a nice day forward...

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 7 Aug 2019 at 21:25, Zeev Suraski  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot  wrote:
>>
>> Considering that you're in favor of keeping the short opening tag in
>>
>> PHP "forever" because you haven't added any kind of other solution
>> either by now neither you see an issue with this... I think the worst
>> situation for language is that there is an option to write non
>> portable code with this unfortunate short tag.
>
>
> Peter,
>
> To put it simply - many of us simply don't see an issue if short tags are 
> with us even at PHP 99, centuries after we're no longer around.  We certainly 
> don't see an issue if it sticks with us until PHP 10.
>
> In fact, it's not that we don't think it's an issue - we actually think 
> that's a Good Thing if it stays, and a Bad Thing if it's removed.
>
> I did my best to illustrate why I think that is the case in my 
> Counterargument 
> (https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags).  I 
> accept that you see things differently.  However, please accept that we also 
> see things differently and are entitled to our opinion just as much as you 
> are entitled to yours.  We simply fail to see an issue with short tags that 
> comes even close for us to want to remove it.  It's not even a close call.  A 
> zero gain and substantial pain associated with a deprecation should be an 
> obvious choice.
>
> To quote Sara Golemon:
> "Frankly, I can't understand why anyone *does* want to drop it."
> (https://twitter.com/SaraMG/status/1158936328450576384)
>
> PHP always had a bias for downwards compatibility.  We went out of our way to 
> come up with creative ways to reinvent the brain of the language several 
> times - while going through hoops to keep code behavior identical.  We did 
> not shy away from breaking compatibility when there was a very strong case - 
> such as the OO model between PHP 4 and 5, the deprecation of magic quotes and 
> the deprecation of safe mode - all painful migrations, but with a very, very 
> strong case that goes well beyond "having more than one way of doing things" 
> or "this creates the possibility of non-portable code".  TBH, I expected 
> folks who are joining the project to accept that, although I guess I was 
> naive as this is clearly not happening (it's only implied in the 'rules', but 
> not actually codified).
>
> Repeating what I said a couple of weeks ago - it seems we've now switched to 
> the business of breaking things almost for the sake of breaking things, and 
> it's really disheartening.
>
> Many of us think that removing short tags does absolutely nothing to improve 
> the portability of PHP code.
>
> I'll go beyond that - the ability to create non-portable code should never be 
> grounds by itself for deprecating a feature (it can be a contributing 
> factor).  There are endless elements that an app can use that can make it non 
> portable.  For example, should we be deprecating support for all databases 
> other than SQLite?  After all, they may not always be installed.  Should we 
> deprecate the SHM extension?  People using it may be stuck if they ever try 
> to deploy to Windows.  What about deprecating disable_functions?  It's a 
> portability disaster that's just waiting to happen.  And I barely even got 
> started.  Almost anything beyond pure PHP logic may not work in all 
> environments, and it's absolutely fine.  It also constitutes absolutely no 
> grounds for starting to go around axing features.
>
> Thankfully, fact is, not all code has to be portable.  The important thing is 
> that those who want to write portable code will be able to do so - while not 
> forcing everyone else to write portable code by enforcing the lowest common 
> denominator.
> I think Chase alluded to the fact that there's substantial anecdotal evidence 
> that the availability of short tags did not actually cause any trouble in the 
> last 20 years.  And when I say anecdotal evidence - I mean that some of the 
> most popular applications on the Web (including the top 3 most popular ones) 
> have been written in PHP, and there's a gigantic framework ecosystem around 
> PHP.
>
> I realize that you think it's a problem that we have two opening tags for PHP 
> - and a major one at that.  It's entirely your right to do so and I 
> wholeheartedly accept it.  Similarly, please accept it that I, as well as 
> many others, simply don't view this as a problem.  And when one does not 
> think there's a problem, one typically does not spend time finding solutions.
>
&

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello,

On Wed, 7 Aug 2019 at 19:03, Chase Peeler  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot  wrote:
>>
>> Hello.
>>
>> On Wed, 7 Aug 2019 at 18:56, Chase Peeler  wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot  wrote:
>> >>
>> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd  
>> >> > wrote:
>> >> >>
>> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
>> >> >> >
>> >> >> > Yes, last time I was asking this, there was a clarification that
>> >> >> > certain people from the group internals can veto particular RFC.
>> >> >>
>> >> >> Please could you point to where this alleged rule has ever been
>> >> >> written down or agreed to?
>> >> >
>> >> >
>> >> > There's indeed no such rule that any individuals have a veto power.
>> >> >
>> >> >>
>> >> >> Although certain people may have claimed this is a rule, it's never
>> >> >> been agreed afaik.
>> >> >
>> >> >
>> >> > I'm not aware of anybody who ever claimed that such a rule existed, 
>> >> > either.  If people are alluding to me - then I don't claim I can veto 
>> >> > anything;  I think it's also clear from what I think about the short 
>> >> > tags deprecation RFC that if I had veto power, that would be an 
>> >> > instance where I'd use it.  The reason we went for V2 aren't because of 
>> >> > a veto, but because of issues in the previous RFC.
>> >> >
>> >> > With that said - the source code of PHP is copyrighted by the PHP Group 
>> >> > - and it's a fact that is mentioned at the top of every PHP source 
>> >> > file.  The PHP Group is mostly inactive, and will likely stay this way, 
>> >> > but under some extreme situations - it might choose to act (if ever - 
>> >> > probably primarily around things that have to do with process).
>> >> >
>> >> >> I think when we adopt a Code of Conduct one of the things we need to
>> >> >> make explicit is that "claiming authority that is not codified" is
>> >> >> explicitly a thing that will not be allowed in internals discussions
>> >> >> as it seems to keep happening and results in a lot of confusion, and
>> >> >> frustration.
>> >> >
>> >> >
>> >> > The more accurate word here is 'if', rather than 'when'. But I don't 
>> >> > think there's a need to wait for a CoC on this one - it should be clear 
>> >> > that no individual has veto powers, but it should be also clear that 
>> >> > not everything is up for a vote.
>> >> >
>> >> > Zeev
>> >> >
>> >>
>> >> Veto has been mentioned here
>> >> https://externals.io/message/105201#105558
>> >>
>> >> I'm not having any issues with veto being used here or not on a
>> >> previous RFC from people that are in the internals since day 1. I
>> >> think we should respect that they have issues with proposals coming up
>> >> in recent years, but hopefully group will also understand us - users
>> >> and new contributors a bit that we just want to have a bit of cleanup
>> >> of legacy things here and there :)
>> >>
>> >> Thanks and have a nice day.
>> >> --
>> >> Peter Kokot
>> >>
>> >> --
>> >> PHP Internals - PHP Runtime Development Mailing List
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> > What powers are available, and to whom they are available, is probably 
>> > something that should be moved to another thread. We currently have at 
>> > least three different discussions going on in this thread:
>> > 1.) The RFC itself
>> > 2.) Default handling of the ini setting
>> > 3.) Whether certain people can veto RFCs.
>> >
>> > To address Andrey's initial concern, which is currently leading to him not 
>> > voting:
>> >
>> > Nobody is vetoing anything. Due to bo

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello.

On Wed, 7 Aug 2019 at 18:56, Chase Peeler  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot  wrote:
>>
>> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd  wrote:
>> >>
>> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
>> >> >
>> >> > Yes, last time I was asking this, there was a clarification that
>> >> > certain people from the group internals can veto particular RFC.
>> >>
>> >> Please could you point to where this alleged rule has ever been
>> >> written down or agreed to?
>> >
>> >
>> > There's indeed no such rule that any individuals have a veto power.
>> >
>> >>
>> >> Although certain people may have claimed this is a rule, it's never
>> >> been agreed afaik.
>> >
>> >
>> > I'm not aware of anybody who ever claimed that such a rule existed, 
>> > either.  If people are alluding to me - then I don't claim I can veto 
>> > anything;  I think it's also clear from what I think about the short tags 
>> > deprecation RFC that if I had veto power, that would be an instance where 
>> > I'd use it.  The reason we went for V2 aren't because of a veto, but 
>> > because of issues in the previous RFC.
>> >
>> > With that said - the source code of PHP is copyrighted by the PHP Group - 
>> > and it's a fact that is mentioned at the top of every PHP source file.  
>> > The PHP Group is mostly inactive, and will likely stay this way, but under 
>> > some extreme situations - it might choose to act (if ever - probably 
>> > primarily around things that have to do with process).
>> >
>> >> I think when we adopt a Code of Conduct one of the things we need to
>> >> make explicit is that "claiming authority that is not codified" is
>> >> explicitly a thing that will not be allowed in internals discussions
>> >> as it seems to keep happening and results in a lot of confusion, and
>> >> frustration.
>> >
>> >
>> > The more accurate word here is 'if', rather than 'when'. But I don't think 
>> > there's a need to wait for a CoC on this one - it should be clear that no 
>> > individual has veto powers, but it should be also clear that not 
>> > everything is up for a vote.
>> >
>> > Zeev
>> >
>>
>> Veto has been mentioned here
>> https://externals.io/message/105201#105558
>>
>> I'm not having any issues with veto being used here or not on a
>> previous RFC from people that are in the internals since day 1. I
>> think we should respect that they have issues with proposals coming up
>> in recent years, but hopefully group will also understand us - users
>> and new contributors a bit that we just want to have a bit of cleanup
>> of legacy things here and there :)
>>
>> Thanks and have a nice day.
>> --
>> Peter Kokot
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
> What powers are available, and to whom they are available, is probably 
> something that should be moved to another thread. We currently have at least 
> three different discussions going on in this thread:
> 1.) The RFC itself
> 2.) Default handling of the ini setting
> 3.) Whether certain people can veto RFCs.
>
> To address Andrey's initial concern, which is currently leading to him not 
> voting:
>
> Nobody is vetoing anything. Due to both the procedural issues (the way the 
> voting was structured with two options) as well as the severity of the issues 
> raised after the voting, another RFC was proposed that supersedes the 
> original RFC. The procedural issues alone were enough to warrant another vote 
> on an RFC that had fixed those issues. This means that, for all intents and 
> purposes, the first RFC never existed. If the current RFC passes, then it 
> will be implemented as proposed. If it fails, then treatment of short tags 
> will remain as it currently is.
>
> I hope you will reconsider your decision to not vote on this new RFC. I 
> understand your concerns. As someone that didn't like the outcome of the 
> first vote either, I also didn't feel that a revote just because a lot of 
> people decided to speak up after the fact was the correct course of action. I 
> don't think that is what is happening here, though.
>
> --
> Chase Peeler
> chasepee...@gmail.com

Just to be more clear here. If the RFC fails then the short opening
tags will stay in PHP for ever. I'm not sure what will change in 5 or
10 years so much so considering the feedback I think we should then
leave them in for ever and enable them by default everywhere and have
two PHP opening tags. Yes, this is what happens when there is no plan
from key people involved here.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd  wrote:
>>
>> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
>> >
>> > Yes, last time I was asking this, there was a clarification that
>> > certain people from the group internals can veto particular RFC.
>>
>> Please could you point to where this alleged rule has ever been
>> written down or agreed to?
>
>
> There's indeed no such rule that any individuals have a veto power.
>
>>
>> Although certain people may have claimed this is a rule, it's never
>> been agreed afaik.
>
>
> I'm not aware of anybody who ever claimed that such a rule existed, either.  
> If people are alluding to me - then I don't claim I can veto anything;  I 
> think it's also clear from what I think about the short tags deprecation RFC 
> that if I had veto power, that would be an instance where I'd use it.  The 
> reason we went for V2 aren't because of a veto, but because of issues in the 
> previous RFC.
>
> With that said - the source code of PHP is copyrighted by the PHP Group - and 
> it's a fact that is mentioned at the top of every PHP source file.  The PHP 
> Group is mostly inactive, and will likely stay this way, but under some 
> extreme situations - it might choose to act (if ever - probably primarily 
> around things that have to do with process).
>
>> I think when we adopt a Code of Conduct one of the things we need to
>> make explicit is that "claiming authority that is not codified" is
>> explicitly a thing that will not be allowed in internals discussions
>> as it seems to keep happening and results in a lot of confusion, and
>> frustration.
>
>
> The more accurate word here is 'if', rather than 'when'. But I don't think 
> there's a need to wait for a CoC on this one - it should be clear that no 
> individual has veto powers, but it should be also clear that not everything 
> is up for a vote.
>
> Zeev
>

Veto has been mentioned here
https://externals.io/message/105201#105558

I'm not having any issues with veto being used here or not on a
previous RFC from people that are in the internals since day 1. I
think we should respect that they have issues with proposals coming up
in recent years, but hopefully group will also understand us - users
and new contributors a bit that we just want to have a bit of cleanup
of legacy things here and there :)

Thanks and have a nice day.
-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello,

On Wed, 7 Aug 2019 at 09:28, Andrey Andreev  wrote:
>
> Hi,
>
> On Tue, Aug 6, 2019 at 8:20 PM G. P. B.  wrote:
> >
> > This RFC supersedes the previous one as stated in the the RFC itself : "
> > This RFC supersedes the previous one and proposes a different deprecation
> > approach." meaning that the previous one is void.
> > I don't know why this is ambiguous and needs to be said once again.
> >
>
> As far as I know, there's been no vote to cancel the previously
> accepted RFC, so ... even though I didn't like the outcome of it, I
> don't understand how it is just made void now. It's pretty easy to
> understand the ambiguity.
>
> I won't be voting on this one due to all of this.
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Yes, last time I was asking this, there was a clarification that
certain people from the group internals can veto particular RFC. So, I
think that this is the case here.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello,

On Tue, 6 Aug 2019 at 19:19, G. P. B.  wrote:
>
> On Tue, 6 Aug 2019 at 19:12, Rowan Collins  wrote:
>
> > On Tue, 6 Aug 2019 at 17:59, Chase Peeler  wrote:
> >
> > > I'm not a voter, but, I have a question. If this fails, does that mean
> > the
> > > original RFC that passed is still in effect?
> > >
> >
> >
> > Yes, this is really ambiguous, and risks the situation being even more
> > confusing than it was before.
> >
> > The "No" column on this RFC already includes people who voted "Yes" on the
> > previous version; is this an indication that they have changed their mind
> > about removing short tags, or that they prefer the original proposal?
> >
> > I think we urgently need to clarify this, and may need to reset the vote
> > with one or more clearer questions.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
>
>
> This RFC supersedes the previous one as stated in the the RFC itself : "
> This RFC supersedes the previous one and proposes a different deprecation
> approach." meaning that the previous one is void.
> I don't know why this is ambiguous and needs to be said once again.
>
> Best regards
>
> George P. Banyard


Thank you for clarification. From what I understand it is the case
where "no" means a status quo and no agreements has been reached on
the original RFC. Since the original RFC has been vetoed and so much
energy was invested from Zeev and some others commentators then I
guess the RFCs fail and we will have two types of opening tags in PHP
for ever. Otherwise, as described, yes.



-- 
Peter Kokot

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

Re: [PHP-DEV] What to do with ext/xmlrpc?

[Peter Kokot]

On Fri, 28 Jun 2019 at 17:57, Christoph M. Becker  wrote:
>
> On 28.06.2019 at 17:49, Peter Kokot wrote:
>
> > On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev  
> > wrote:
> >>
> >>> ext/imap should follow the same road.
> >>>
> >>> BTW, if we want to keep this extension, we need to consider the bundled
> >>> library as a fork, maintained by US (and drop support to build using the
> >>> system library, if present)
> >>>
> >>> So, any new volunteer to maintain this extension, will also have to
> >>> maintain the library.
> >>
> >> This looks unlikely, so we shouldn't count on it happening. I think we
> >> should just move them to PECL and if somebody shows up, we can always
> >> move it back.
> >
> > Hello, sorry for bumping this one. Is the ext/xmlrpc extension also on
> > the list to be unbundled maybe for PHP-7.4?
>
> AFAIK, it isn't.  Sorry for not having pursued this.
>
> --
> Christoph M. Becker

Then I can create an RFC to unbundle it from the core and move it
together with the libxmlrpc library fork into PECL. Having
unmaintained extensions in the core and marked as experimental for the
last 18 years is not good I think. Is there enough time to do all this
until July 22nd (7.4 feature freeze)?

-- 
Peter Kokot

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

Re: [PHP-DEV] What to do with ext/xmlrpc?

[Peter Kokot]

On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev  wrote:
>
> Hi!
>
> > ext/imap should follow the same road.
> >
> > BTW, if we want to keep this extension, we need to consider the bundled
> > library as a fork, maintained by US (and drop support to build using the
> > system library, if present)
> >
> > So, any new volunteer to maintain this extension, will also have to
> > maintain the library.
>
> This looks unlikely, so we shouldn't count on it happening. I think we
> should just move them to PECL and if somebody shows up, we can always
> move it back.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello, sorry for bumping this one. Is the ext/xmlrpc extension also on
the list to be unbundled maybe for PHP-7.4?

-- 
Peter Kokot

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

Re: [PHP-DEV] Wiki display problem

[Peter Kokot]

On Wed, 12 Jun 2019 at 14:29, Sascha Schumann
 wrote:
>
> Please try again.
>
> Sascha

Great. Now it works. Thank you so much, Sascha...

-- 
Peter Kokot

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

Re: [PHP-DEV] Wiki display problem

[Peter Kokot]

Hello,

On Tue, 11 Jun 2019 at 13:18, Christoph M. Becker  wrote:
>
> On 11.06.2019 at 13:07, Sascha Schumann wrote:
> > Cert is fixed on the machine now.
>
> Thanks!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Maybe looking at this might be also good one day. When doing

wget https://downloads.php.net/~cmb/php-7.3/php-7.3.6RC1.tar.xz

this is the output when not using --no-check-certificate:

Resolving downloads.php.net... 104.236.32.144, 2604:a880:800:10::2dd:1
Connecting to downloads.php.net|104.236.32.144|:443... connected.
ERROR: cannot verify downloads.php.net's certificate, issued by
'CN=Thawte TLS RSA CA G1,OU=www.digicert.com,O=DigiCert Inc,C=US':
  Unable to locally verify the issuer's authority.
To connect to downloads.php.net insecurely, use `--no-check-certificate'.

For the www.php.net page this works ok:
wget https://www.php.net/distributions/php-7.3.6.tar.xz

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Sat, 11 May 2019 at 20:56, Peter Kokot  wrote:
>
> Not trying to rush anyone to something they have no energy working on
> anymore here but what's the plan here then? And what plan is there
> with these short tags on the long run?

I'm just checking then why is this RFC in the pending implementation
state if basically we're on a way to have the short opening tags in
PHP for ever... Maybe we should then enable them by default to have
the other way around situation of having both tags for few 10 years
and then ditch the long one if it's not going to be deprecated in PHP
7.4 and decided what to do with them?

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

-- 
Peter Kokot

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

Re: [PHP-DEV] MODERATE spam

[Peter Kokot]

Hello,

On Sat, 18 May 2019 at 22:02, Peter Kokot  wrote:
>
> Hello,
>
> On Sat, 18 May 2019 at 12:06, Joe Watkins  wrote:
> >
> > Hi all,
> >
> > Does anyone know what is the cause of all the spam from the announce
> > mailing list? I'm not sure who is getting it, but I'm getting a few emails
> > a minute sometimes, it's rather annoying ...
> >
> > Can someone do some magic, and make it go away please ?
> >
> > Cheers
> > Joe
>
> 100+ daily spam emails here also. Considering that these don't get to
> other mailing lists, they can get regulated probably...
>
> --
> Peter Kokot

Filter created with * from these lists going to spam directory now.
Case solved. Apologies in advance if I miss something important on
that list because this is not a list for my standards if so many spam
messages can pass through.

Regards.

-- 
Peter Kokot

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

Re: [PHP-DEV] MODERATE spam

[Peter Kokot]

Hello,

On Sat, 18 May 2019 at 12:06, Joe Watkins  wrote:
>
> Hi all,
>
> Does anyone know what is the cause of all the spam from the announce
> mailing list? I'm not sure who is getting it, but I'm getting a few emails
> a minute sometimes, it's rather annoying ...
>
> Can someone do some magic, and make it go away please ?
>
> Cheers
> Joe

100+ daily spam emails here also. Considering that these don't get to
other mailing lists, they can get regulated probably...

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?

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

Re: [PHP-DEV] PHP Docker images

[Peter Kokot]

On Sat, 11 May 2019 at 06:12, Pierre Joye  wrote:
>
> On Fri, May 10, 2019, 2:06 PM Peter Kokot  wrote:
>
> >
> > The images for such C software are one of the more useless ones. Snaps
> > or custom Linux repositories are the way to go here. Because of the
> > installation time. Building several extensions from source is really
> > time consuming...
>
>
> Maybe this is exactly why docker images are nice. You do not build them but
> once (on dockerhub f.e.) and users only grab them. Just maybe...
>
> best
> Pierre

Yes, theoretically :) There are actually more cases where you will
build them more than once. Almost several times per day. For example,
to build intl extension one must do:
docker-php-ext-install intl and also install dependencies that belong
to it. Imagine now doing this for a normal PHP environment which is
about several more extensions, some pecl ones and you get to an
installation time of almost 10 minutes (over the thumb). Docker
registries are not that common as we think. And with building the same
Docker image using Linux repositories the installation becomes a
matter of seconds (without worrying which extensions need another apk
add --no-cache libfoo or apt install libfoo-dev) and then also
cleaning those dev packages after the build.

-- 
Peter Kokot

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

Re: [PHP-DEV] PHP Docker images

[Peter Kokot]

Hello,

On Tue, 7 May 2019 at 07:01, Martins Sipenko  wrote:
>
> Hi,
>
> Has PHP community thought about providing official PHP Docker images?
>
> I'm aware there are php images available on Docker hub, but as their docs
> state those are not to be confused with any official php image provided by
> php upstream.
>
> I think it would be great to have official images be released on the same
> day as PHP, currently there is a delay. Also I think it would be great to
> provide nightly snapshot builds of unreleased PHP versions, these
> containers could then be used by frameworks/libraries/applications to test
> against upcoming PHP versions in CI.
>
> Let me know your thoughts, and what would the next steps be if this is
> something we want to do.
>
> Martins

The images for such C software are one of the more useless ones. Snaps
or custom Linux repositories are the way to go here. Because of the
installation time. Building several extensions from source is really
time consuming... You will notice this one day maybe. Otherwise, PHP
is really not doing enough to make the installation and life of
packagers better yet. It will get worse actually from release to
release each year if we don't start refactoring some things. And the
manual for the installation of PHP that doesn't mention such options
(but on the other hand mentions installing PHP on servers that are
dead for decade) is also another story that plays a role here.

-- 
Peter Kokot

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

Re: [PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

[Peter Kokot]

Hello,

On Sat, 9 Feb 2019 at 17:38, Gabriel Caruso  wrote:
>
> Em sáb, 9 de fev de 2019 às 06:08, Mark Baker 
> escreveu:
>
> > On 06/02/2019 08:13, Mark Baker wrote:
> > > Looking at the Voting Eligibility discussion going on at the moment.
> > >
> > > I, like many others, participated in the last testfest 18 months or so
> > > ago. Did the results from that ever get merged? Or have they simply been
> > > discarded or forgotten? If merged, they certainly don't show up in the
> > > contributions list posted aganst the Workflow and Voting RFC Eligibility
> > > list: yet all those who participated in the testfest care about the
> > > language enough to get involved
> > >
> > >
> > Thank you. It's good to see merging has started. I appreciate your work,
> > as I'm sure will many of those who contributed through the TestFest
> >
> >
> > --
> > Mark Baker
> >
> >   _
> > |.  \ \-3
> > |_J_/ PHP |
> > || |  __  |
> > || |m|  |m|
> >
> >   I LOVE PHP
> >
> >
>
> Hello everyone.
>
> I've reviewed a couple of those PRs, closing some ZPP Failures tests and
> duplicated ones and now we have 94 to go. Some of them I've left a comment
> to adjust the test to get merge, others, I'm not familiar with the
> extension/function/test to approve. If someone wants to take a look and
> help us finish this task, I'd appreciated it :)
>
> https://github.com/phpcommunity/phptestfest-php-src/pulls
>
> Best,
> --
> Gabriel Caruso

I want to thank everyone who have sent their pull requests to the test
fest repository or have in any other way joined and participated in
the PHP test fest event.

I thought we could merge all the pull requests properly in few months
but unfortunately that's it from my side in the given time frame that
was set for this part. We have merged several pull requests that could
be added in the upstream repository others should be done manually but
I simply don't have time to go through each manually anymore. If
anyone would like to see their contribution noted in the php-src
repository, please reopen the pull request in the php-src repository
directly. It's very simple (and in most cases hopefully welcoming
enough) to send your pull request there. If not ping me up to check
your pull requests per manual basis.

A friendly nudge to the organizers... Next time, don't be shy and
please please avoid doing forks of this repo and let's do the noise
directly on the php-src repo. As we see, it is almost near impossible
to solve this properly and give everyone credits they deserve and
merge all the pull requests there without manual commits and rechecks
without the help of the internals people.

Cheers and thanks.


-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [Vote] Change the precedence of the concatenation operator

[Peter Kokot]

Hello,

On Fri, 3 May 2019 at 16:19, Niklas Keller  wrote:
>
> Hey Bob,
>
> in the RFC you mention:
>
> > While this is a subtle behavior change in that it will give different 
> > outputs without notice or warning, it is trivially possible to statically 
> > analyze the code and find all instances where this happens.
>
> On the other hand, there's:
>
> > PHP 8, with a deprecation notice in PHP 7.4 upon encountering an 
> > unparenthesized expression containing an '.' before a '+' or '-'.
>
> So there will be a notice if the second vote passes and the output
> changes in PHP 7.4.
>
> Regards, Niklas
>
> Am Mi., 1. Mai 2019 um 00:41 Uhr schrieb Bob Weinand :
> >
> > Hey,
> > As announced yesterday, I'm now starting the vote on this RFC.
> >
> > I'm confident that the impact is really that minimal that a relatively 
> > quick deprecation and change path is preferred.
> >
> > https://wiki.php.net/rfc/concatenation_precedence
> >
> > The vote ends on May 15.
> >
> > Thanks,
> > Bob

Thank you for the RFC. Apologies for not responding here sooner. I
just want to point out one thingy here also (that is becoming sort of
a pattern recently and also because this has been pointed out at
another RFC that is causing issues with some people, yet no issues
here).

The removal of some feature (which causes a BC break) in PHP 8.0
should always emit a deprecated warning if that is possible to do on
given time in the code or to detect this feature. We could say that
situation is completely similar to the removal of the short opening
tags. If there is something to be removed or changed with BC break
effect in major release, the deprecation warning is self-evident and
therefore I'm not sure why the additional vote here. Because again, an
edge case scenario we could get a changed functionality in PHP 8 and
no warning in PHP 7.4.

Just as an example and a bit of an additional info how the upgrades
from minor to major releases can go smoother.

Other than that, all looking good and thank you for your work.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

On Wed, 1 May 2019 at 00:56, Stanislav Malyshev  wrote:
>
> Hi!
>
> > Worth noting another inconsistency here that we've missed. PHP 7.4 has
> > introduced many BC breaks actually already. Without this level of
> > problems:
>
> Exactly, without. There's a difference between removing an unmaintained
> extension which is barely used and setting people up for displaying
> their sources if they use slightly outdated libraries. And there's a
> difference between explicitly making a decision and not even bothering
> to discuss this mammoth of a BC break until the vote is finished. So to
> me it's more like "elephant in the room" scenario - we've got a process
> failure here. We are on the course to correct it, but it's a failure
> nevertheless.

It is a BC break nevertheless no matter how much time it takes to
change the code. The level of the impact cannot be measured like this.
Every app will have different things to fix. So saying that this
particular change will break the internet is not realistic without any
numbers. If PHP is on a course to fix the BC break strategy then good
(for example, BC breaks allowed in major releases, minor releases
including only new features etc). Upgrading PHP version would be then
a breeze probably but very complex to maintain the code in the repo
(at least according to the release cycles of 5+ years to get to a
major version). However, I'm not sure I'm seeing such direction or
anyone expressing it to do this at least according to many here and
even this discussion. Because, from what I think here more is that
we're discussing how to keep the short tags forever and how to remove
them as soon as possible. There is a difference in what people want
here. And majority of those not in favour of the removal in PHP 8,
want them to have forever and basically want to change the issue of
removing the tags in the first place. I haven't seen any step forward
from this point yet and what kind of a different removal strategy
(compared to Nikita's suggestion) would work.

> > The deprecation in PHP 7.4 (or even if there wouldn't be any
> > deprecation here at all) and removal of some short tags in PHP 8 is
> > the least of users problems I think.
>
> You mean wddx removal is much bigger problem for users than the
> potential for their code to be sent out instead of executed? If so, we
> must be living in very different words, because for me the former is a
> blip on the margin of the radar and the latter is a "world on fire, do
> not upgrade under any circumstances" scenario. I could easily ignore the
> former and I wouldn't dare to upgrade any production for the latter
> without long process of verification that would 100% ensure there's no
> bad tags hiding in any code, any dependency, any library, etc. Maybe
> it's what the RFC authors want, but it's certainly a giant difference in
> BC impact.

I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly. Because we've simply upgraded
all very very long time ago or in other words even never thought of
writing something in these tags anymore. Well, obviously this might be
for someone else a problem on a scale of an elephant, that I don't
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used anymore in any case. :) Because obviously a very
large number of people would like to have more clear definition of
what is opening PHP tag.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Tue, 30 Apr 2019 at 20:25, Zeev Suraski  wrote:
>
> On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans  wrote:
>
> > On Mon, 29 Apr 2019, Zeev Suraski wrote:
> >
> > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. 
> > wrote:
> > >
> > > > I think this just boils down to what is an acceptable majority, if
> > > > 2/3 is not enough then 3/4 but this is another debate altogether.
> > > >
> > >
> > > I've argued in the past that it would make sense to require a 9/10
> > majority
> > > for RFCs.  Very few RFCs that passed - only cleared a 2/3 majority.
> > > Usually (in the vast majority of cases), it either clears a nearly
> > > unanimous vote - or it doesn't even come close to 2/3.
> > >
> > > RFCs that have a high number of votes (i.e., that people feel strongly
> > > about), and barely pass the 2/3 mark - are controversial and saw
> > division.
> > > Yes, it means that out of the (almost random) group of people who are
> > > currently enabled to vote by our (flawed) voting system
> >
> > If you think it's flawed
>
>
> It's not that I think it's flawed - I know it's flawed.  It doesn't
> implement what was agreed upon when the Voting RFC was enacted.
>
>
> > , you know that the RFC process is there for
> > anybody to change it. Joe already managed twice towards what you
> > suggested in your stalled RFC:
> >
> > - https://wiki.php.net/rfc/abolish-short-votes
> > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
> >   against this one to raise the barrier from 50%+1 to ⅔rds).
> >
>
> I'm well aware of it.  In doing that, I think we greatly complicated the
> prospects of fixing the voting eligibility - which is an infinitely hotter
> potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
> little touchy subjects - unlike the topic of who gets to vote, or the
> prospect of moving to a consensus-based system.
>
> > It's absolutely fine to dislike short tags.  It's absolutely fine to
> > > believe it shouldn't have been introduced.  But the gap between that,
> > > and thinking it's fine to remove it - is very, very big.
> >
> > But the fact is that the RFC passed. And retroactively changing rules
> > because somebody don't agree with a decision is making a farce out of
> > the process.
> >
>
> I've detailed the issues with the RFC in my other reply.
>
> I'm well aware that I'm spending quite a bit of 'credit capital' by
> weighing in on this, and I'm enjoying it roughly as one would enjoy having
> their tooth pulled out without anesthesia (which still pales in comparison
> to what it would take to fix our voting process, which will probably be
> akin to having an entire set of teeth pull out in the same way).   The
> reason I'm still doing it is that it's clear this RFC was flawed in its
> voting options, its substance, and the level of discussion that surrounded
> it (the last one is my opinion, the first two are facts) - and it will have
> HUGE implications on hundreds of thousands if not millions of users.  So as
> I said when I first engaged this thread - as much as I'm 'enjoying' this, I
> prefer to take the personal hit and do whatever I can to prevent our users
> from taking the hit.
>
> If we are to inflict this hit on our users - we need to have each and every
> t crossed and i dotted.
>
> Zeev

Some languages out there have an idiom for this kind of a situation:
This thread right here is making an elephant out of the fly. Meaning
something is exaggerating or make something more serious than it
actually is.

Worth noting another inconsistency here that we've missed. PHP 7.4 has
introduced many BC breaks actually already. Without this level of
problems:
- *nix build system now uses pkg-config and basically has changed so
many configure options that building this is a completely new chapter
on its own
- removed wddx
- removed interbase
- entire Backward Incompatible Changes section in the UPGRADING file:
https://github.com/php/php-src/blob/PHP-7.4/UPGRADING

The deprecation in PHP 7.4 (or even if there wouldn't be any
deprecation here at all) and removal of some short tags in PHP 8 is
the least of users problems I think.

If the next RFC on this topic would happen (in my opinion it is
pointless) it should make only something more clear. That is how to
remove them. In PHP 8.0 directly as is now the result of this RFC or
in PHP 9.0 removal and in PHP 8.0 using a compilation error. Anything
in between is a more or less a revert of the origina

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Wed, 10 Apr 2019 at 12:44, G. P. B.  wrote:
>
> Hello Internals,
>
> As there have been no further comments the voting for my RFC [1] to
> deprecate PHP's
> short open tags has started and will run for two (2) weeks.
>
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags

I want to thank you for this RFC, for your time dedicated to it, for
the actual implementation and everything. You have done everything
correct and also the general idea i.e. removing these legacy tags in
either PHP 8.0 or not was completely correctly pointed out and RFC (at
least according to the current PHP RFC standards) met all the criteria
to get into implementation step. Everyone who is working with PHP
development knows that these short tags are not meant to be used
anymore. Also everything was correctly accepted and the numbers are
correct.

This entire thread is also showing the integrity, intelligence level
of the PHP a bit but one day maybe these legacy leftovers can be
removed, hopefully... Because they really should. So let's not give up
and let's find some normal solution here... RFC and results are quite
clear but maybe Nikita's solution is good enough for all:

- Deprecation warnings in PHP 7.4 (RFC criteria met, people here happy or not)
- PHP 8.0 complete compile error without any option to further use
them anymore (RFC criteria sort of met -!!!, and the reason of
pretending that the legacy apps will work ok on PHP 8.0 also met)
- Actual removal in PHP 9 (because this is then the logical next
step). Removing something like this in PHP 8.1 is not following
semantic versioning at all. Either removal in 8.0 or 9.0.

Cheers and thanks.

--
Peter Kokot

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

Re: [PHP-DEV] Retiring PHP's Mirror Program

[Peter Kokot]

Hello,

On Mon, 1 Apr 2019 at 16:26, Robert Hickman  wrote:
>
> Is there any reason not to use 'php.net' raw without the 'www'?
>

Additional question: Can we maybe get an insight of a canonical,
recommended URL which should be used now? Is this www.php.,net or is
it php.net without www.

Worth noting that now both domains result in 200 OK (previously there
was a redirection done from php.net to www.php.net):
curl -IL https://www.php.net
curl -IL https://php.net

Thank you...
-- 
Peter Kokot

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

Re: [PHP-DEV] Required Make version

[Peter Kokot]

Hello,

On Wed, 17 Apr 2019 at 01:08, Johannes Schlüter  wrote:
>
> On Di, 2019-04-16 at 09:46 -0600, Levi Morrison wrote:
> >
> > I'd be happy to work help with the CMake port, as I know it a decent
> > bit, but I don't have enough time to champion the whole thing.
> >
>
> That has been done ages ago:
> http://svn.php.net/viewvc/php/cmake/
>
> Back then it didn't have any uptake because it was uncommon and people
> don't like to change. (and maybe some technical reasons where some
> hidden sauce in PHP's build system allows some magic)
>
> A key factor for PHP's build system (imo) back the was that PHP's
> incremental build was *a lot* faster (typical development cycle: touch
> a single file and type "make") than CMake (while CMake+make is more
> correct since it also checks touched headers) nowadays we have SSDs,
> which makes this a bit less of an issue, and CMake supports ninja,
> which eventually might be faster.
>
> johannes

Thanks everyone for their time to write answers here. Basically, the
make supports more implementations besides only GNU. This has been
resolved in a very simplistic way.

About the CMake I'll check it out for sure more... The *nix build
system has been now so much cleaned that adding CMake buildsystem
beside the autotools and windows one could be done nicely I think. A
bit more cleaning should be done of that implementation in the SVN
example. Like adding less files in the project root directory and
every single src folder out there, removing outdated things, adding
new things and fine tunings etc... But yes, quite modern looking thing
with at least active development behind compared to Autoconf stuff and
non standard windows build system without much docs...

Only concern here is PHP's openness to change and accept the change.
I've noticed that so many things here can't be changed actually that
it is becoming a deal breaker to fix things and mover this forward. To
invest one's free time in improving something that in the end
internals people will change according to what they think should be
done here is a bit tricky and I'll leave it be for now. People who
have made cmake implementation on the link above, probably realize and
understand this more than we in this discussion.

And besides, the cmake build system could even be done as a separate
project out of php for starters if anyone might be interested in doing
that.
-- 
Peter Kokot

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

Re: [PHP-DEV] Alternative approach to short tags deprecation

[Peter Kokot]

Hello,

On Thu, 25 Apr 2019 at 09:15, Nikita Popov  wrote:
>
> Hi internals,
>
> As already discussed in the corresponding voting thread, the deprecation of
> short tags as proposed has a high risk of causing inadvertent source code
> leakage. The RFC proposes to change the default of short_open_tag from On
> to Off in PHP 7.4. Any website using short_open_tags without explicitly
> enabling it (relying on the default) will leak source code unless proper
> precautions are taken before switching to PHP 7.4.
>
> Disregarding the question of whether short tags should be removed at all
> (let's keep that question in the other thread), I do think we need to
> reconsider the deprecation approach. In particular, I would like to propose:
>
> In PHP 7.4:
>  * The default value of short_open_tag remains as is and enabling
> short_open_tag does not generate a deprecation warning (otherwise PHP would
> warn in a default config).
>  * If short_open_tag is enabled: The first use of  deprecation warning. (Potentially every use could throw a deprecation, but
> generally, if  noise in the error log.)
>  * If short_open_tag is disabled: 
> In PHP 8.0:
>  * The default value of short_open_tag remains as is and enabling
> short_open_tag does not generate a deprecation warning or error.
>  * If short_open_tag is enabled: Any use of   * If short_open_tag is disabled: 
> At a later point in time:
>  * The short_open_tag option is removed.
>  * 
> The advantage of such an approach would be that no source code leakage
> could occur when switching to PHP 7.4 or PHP 8.0. The disadvantage is that
> we'll only be able to fully remove short tags support at a later point in
> time.
>
> Thoughts?
>
> Regards,
> Nikita

Sure. I think we can do that also for people who haven't upgraded
their code yet and can do that at their own pace by ~ 2025/2026. By
that time the rest of us will be using "Jitted", "asynced", more
consistent, and slick-syntaxed PHP everywhere already so they can
catch us up... :) No worries.

The approach described sounds ok to me. Would be also good to think
even more in advance - like making http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Wed, 24 Apr 2019 at 23:12, Björn Larsson  wrote:
> Hi,
>
> I did a quick check on two open source libraries that I'm using,
> namely Smarty templating library and Revive ad server. A quick
> glance at hand shows that they both uses the  latest release. Smarty 3.1.33 was released 17/9 2018 and
> Revive 4.2.0 was released 23/4 2019.
>
> It would be interesting to see if there is any benefit in fixing this
> feature for these two well-established libraries? I think that both
> these libraries will adapt, but how long will it take... Regarding
> your points above I don't see any added value that this feature
> brings for me as a user of these two libraries, since I'm quite
> happy with the functionality they provide as is. How then the
> developers see it is not up to me to judge.
>
> r//Björn L
>

I'm not sure if we're looking at the same libraries and versions here
but both of these use normal opening tags in the code for quite a
while:
https://github.com/revive-adserver/revive-adserver
https://github.com/smarty-php/smarty

Keywords open source, PHP, and short opening tags don't go together
anymore neither people coding in PHP are using these anymore for a
very long time. If they postpone upgrades and neglect good coding
practices, nothing can help them improve or fix their apps.
-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Wed, 24 Apr 2019 at 19:44, Chase Peeler  wrote:
>
> On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta  wrote:
>
> > On Wed, 24 Apr 2019, 19:25 Christian Schneider, 
> > wrote:
> >
> > > Am 24.04.2019 um 19:13 schrieb Marco Pivetta :
> > > > On Wed, 24 Apr 2019, 19:10 Christian Schneider,  > >
> > > wrote:
> > > > Am 24.04.2019 um 19:01 schrieb Peter Kokot :
> > > > > just a friendly reminder that by the time one writes an email here
> > > > > these tags can be already replaced with the usual ones.
> > > >
> > > > A friendly reminder that some people are hosting customer code which
> > > they do not want to touch but will get support requests once the code
> > > breaks.
> > > >
> > > > - Chris
> > > >
> > > > That's normal? Everyone has projects to maintain, and breaking changes
> > > are common: they're gonna call you for one anyway: if you don't like
> > that,
> > > then you are in the wrong line of business.
> > >
> > > See Chase Peeler's point: A breaking change should have a reward big
> > > enough to justify it.
> > > And that's what where we (including Zeev Suraski and other core
> > > developers) disagree.
> > >
> > > - Chris
> > >
> >
> > Run a fixer: they are out there, and they are extremely stable too.
> >
> > Also a good chance to finally take a look at code that has been rotting in
> > a hard drive for too much time.
> >
> All of that takes time though. I have 6,787 short opening tags found. Even
> if I use a fixer to generate a diff, or, to fix them and then examine the
> diff in a pull request... that's going to take a LOT of time. It's going to
> start getting messy if I find false positives and need to exclude changes.
> It still doesn't address the impact of changes that aren't found. Are you
> 100% positive that the fixers out there will catch EVERY single instance?
> php-cs-fixer doesn't update  dynamic code, then that's not getting caught.
>
> The output from php-cs-fixer just generated a diff file that was 161,000
> lines long. But yea, that's something I can scan through real quick and
> make sure nothing is going to get broken. No chance I'll miss something
> either.
>
> I would LOVE to have the time to go through our legacy code and clean out
> old stuff. We have a lot of technical debt that, while we aren't paying it
> off at the moment, it's gaining any interest either. We also have plenty
> that is. It's tough to justify putting off the stuff that is gaining
> interest to focus on stuff that isn't so we can fix short tags.
>
> I don't work for a software company. I develop an internal application for
> a non-software company. There are 2 other developers and enough work for 10
> developers. It's going to be VERY hard for me to get management to approve
> putting off projects that have a direct impact on our business in order to
> upgrade to PHP 8 when that time comes. I think you are going to find that's
> a pretty common occurrence, and the adoption rate of PHP 8 is going to be
> VERY low. Especially when more and more user-friendly alternatives like
> python and node are coming along. It was one thing when the options were
> RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
> going to provide additional user friendly opportunities in the next couple
> of years leading up to PHP8.
>
> Can someone PLEASE tell me the positive gains this RFC will accomplish that
> justifies risking:
> 1.) Losing market share
> 2.) losing credibility
> 3.) removing a large number of libraries that are fine from a technical
> aspect, but will stop working due to the existence of  4.) new security risks (code leaks that are more likely than the code leaks
> the RFC seeks to prevent)
>
> And, please don't use the existence of code fixers to justify this unless
> you are willing to demonstrate how it's quick and easy to go through a
> 161,000 line diff file or are willing to 100% guarantee that the fixer will
> not break anything, will not fix anything it shouldn't, and will not miss
> anything it should fix.
>
>
>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com

I've done few commits with about 8k files changed with very repeating
changes like this and without breaking anything. It will take you
about 30minutes... Let's say, one hour for also taking a break from
all the scrolling the git diff and to return the merge the next day
after another check or something like this.

The change (speaking for 8k files using short opening tags converted
to http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones. Here is an
example of running php-cs-fixer to replace the legacy tags to the full
opening tags:

php-cs-fixer fix --rules=full_opening_tag --diff --dry-run
/path/to/php/files/with/short/tags


And then actually replacing them (without dry run):

php-cs-fixer fix --rules=full_opening_tag --diff
/path/to/php/files/with/short/tags

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Wed, 24 Apr 2019 at 13:29, G. P. B.  wrote:
>
> Hello Internal,
>
> The two weeks of voting have now ended.
> The results are 38 for and 18 against (total 56) for the primary vote to
> deprecate PHP's short open tag in PHP 7.4.
> This passes in favor with 68%.
>
> The results are 42 for and 15 against (total 57) for the secondary vote to
> remove PHP's short open tag in PHP 8.
> This passes in favor with 74%.
>
> Thanks for everyone who voted on this issue.
>
> Best regards
>
> George P. Banyard
>
> >

Great! It was about time this got removed. And it is a perfect timing
also - PHP 8.0 when BC breaking changes can be done. Thank you so much
for moving this forward. People who are thinking of supporting some
legacy applications on the upcoming PHP 8 will be unfortunately a bit
surprised with all the removed features and will have other bigger
issues adjusting their code compared to a really simple replace of http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Arrow functions / short closures

[Peter Kokot]

Hello,

On Wed, 17 Apr 2019 at 12:58, Nikita Popov  wrote:
>
> Hi internals,
>
> I've opened voting on the arrow functions RFC. The vote closes May 1st.
>
> https://wiki.php.net/rfc/arrow_functions_v2#vote
>
> The RFC uses the fn($x, $y) => $x*$y syntax as originally proposed.
>
> Regards,
> Nikita


Thanks for the RFC. The status of the document should be probably
updated from "Status: Under Discussion" to "Status: Voting"
-- 
Peter Kokot

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

[PHP-DEV] Required Make version

[Peter Kokot]

Hello,

people familiar with the PHP *nix build system today can be probably
counted on the fingers of two hands, so I'm hoping to get some answer
also here.

Does anyone maybe still have any insights on which Make version does
PHP require or silently specify as a minimum? GNU make? POSIX make?
Maybe some GNU make minimum version? 3.81? etc...

Currently, there are two steps where different make can be used:

1.) ./buildconf
(here GNU make is required because of using the conditional macro
assignment operator ?= in build/build2.mk file)

2.) make step after ./configure
(here POSIX make can go through more or less ok).

This is seen, for example, on the Solaris systems where doing this:

./buildconf

causes:

make: Fatal error in reader: build/build.mk, line 22: Badly formed
macro assignment

so, this needs to be done:

MAKE=gmake ./buildconf

however, this works then ok:

./configure
make

Is this confirmed and ok with everyone that GNU make is the minimum
required derivative for PHP to be used? Or should software such as PHP
be an example and use POSIX compatible make?

Reason for asking this: https://github.com/php/php-src/pull/4025 and
similar improvements...

Thank you.

-- 
Peter Kokot

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

Re: [PHP-DEV] Re: PHP 8 Preview Releases

[Peter Kokot]

Hello,

On Fri, 29 Mar 2019 at 15:35, Dmitry Stogov  wrote:
>
> Hi Arvids,
>
>
> It's possible to test JIT with PHP-7.4 building PHP from 
> https://github.com/zendtech/php-src/tree/jit-dynasm-7.4
>
> But this branch is not going to be supported anymore.
>
>
> Thanks. Dmitry.
>
> 
> From: Arvids Godjuks 
> Sent: Friday, March 29, 2019 5:17:41 PM
> To: Joe Watkins
> Cc: Dmitry Stogov; release-manag...@php.net; PHP internals
> Subject: Re: [PHP-DEV] Re: PHP 8 Preview Releases
>
> Hello,
>
> I'd like to add that as the userland developer, it would be nice to be able 
> to build JIT against an active branch (a.k.a PHP 7.4), cause if PHP 8 brings 
> enough changes, it would not be realistic to fix our apps to be compatible 
> with PHP 8 months or years away from actual release.
>
> пт, 29 мар. 2019 г. в 15:58, Joe Watkins 
> mailto:krak...@gmail.com>>:
> Hi Dmitry,
>
> I'm not suggesting we do it right now, I'm suggesting we look at the
> planning of it right now as it deviates from our normal release cycle.
>
> At the moment we should just consider how we want it to work, including
> when it should start ...
>
> Cheers
> Joe
>
> On Fri, 29 Mar 2019 at 14:42, Dmitry Stogov 
> mailto:dmi...@zend.com>> wrote:
>
> > Hi Joe,
> >
> >
> > I think, PHP-8 preview is too early.
> >
> > We even didn't freeze PHP-7.4 yet, and PHP-8 didn't get any new major
> > features (may be I forgot something) only deprecations and some internal
> > improvements
> >
> > .
> >
> > According to JIT, it's probably going to be changed a lot in the nearest
> > future.
> >
> >
> > Thanks. Dmitry.
> > --
> > *From:* Joe Watkins mailto:krak...@php.net>>
> > *Sent:* Friday, March 29, 2019 3:40:04 PM
> > *To:* release-manag...@php.net<mailto:release-manag...@php.net>; PHP 
> > internals; Dmitry Stogov
> > *Subject:* PHP 8 Preview Releases
> >
> > Morning internals,
> >
> > Since we now have a result for JIT and we know it will be included in PHP
> > 8, I think it's time to visit the idea brought up in discussion to have
> > preview releases of PHP 8.
> >
> > I'm interested in hearing what kind of schedules we think are going to be
> > useful - it's tempting to say let's track PHP-7.4 releases, possibly with a
> > bi-monthly interval, but I'm not sure if that may be too soon, or too slow,
> > or too fast.
> >
> > Thoughts please (especially from Dmitry) ?
> >
> > Cheers
> > Joe
> >
> >
> >
>
>
> --
> Arvīds Godjuks
>
> +371 26 851 664
> arvids.godj...@gmail.com<mailto:arvids.godj...@gmail.com>
> Skype: psihius
> Telegram: @psihius https://t.me/psihius

PHP 8.0 is definitely tempting and wanted. First phase is definitely
for users to have option to install it manually from Git as is now.
The snapshot script:
https://github.com/php/php-src/blob/master/scripts/dev/snapshot
is on my list to improve a bit to have at least an option to get
archive package out of the current Git state. Between this and the
official downloadable release there isn't much difference in doing the
build manually.

What is more important for the end users is to have Docker image(s)
available or even some Linux packages.

Also, practice shows that the dev branch in state before the few
months prior to the releases contains really a lot of bugs and also
build system bugs that normal users will have serious issues setting
this up. If Linux packagers and 3rd party repository maintainers can
help here, that would be also one way to go since PHP seems to be very
far away from doing such steps on the php.net side...

But to have PHP 8.0.0alpha1 version available at this and this date
before the PHP 7.4 release is quite challenging for all, I think.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] [Result] JIT

[Peter Kokot]

On Fri, 29 Mar 2019 at 09:57, Dmitry Stogov  wrote:
>
> Hi @internals,
>
>
> The JIT RFC https://wiki.php.net/rfc/jit is accepted to be merged into PHP-8 
> only.
>
> I'm going to perform the actual merge on Monday morning and then start 
> working on deeper integration of JIT with VM.
>
>
> Thanks. Dmitry.

Great. No rush, we now have more than a year until Jit will be happening then :)

Otherwise, I'm really looking forward seeing this in action. Thank you
for the splendid work.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags

[Peter Kokot]

Hello,

On Mon, 25 Mar 2019 at 14:02, G. P. B.  wrote:
>
> Hello internals,
>
> I would like to start the discussion about the deprecation of PHP's short
> open tags:
> https://wiki.php.net/rfc/deprecate_php_short_tags
>
> As this is my first RFC all feedback is welcome.
> However, due to the nature of the RFC and it being self-contained, the
> planned date to
> beginning voting this RFC is after the mandatory two weeks discussion
> period and would
> start on Monday the 8th of April (2019-04-08) and be open for two weeks
> until Monday the
> 22nd of April (2019-04-22).
>
> Best regards
>
> George P. Banyard

Short opening tags are by default disabled in the php.ini settings on
the majority of PHP installations. This means that writing modern PHP
code shouldn't use these anymore because the code isn't properly
portable or let's say it is less portable. On top of all removing
these would also simplify things a bit - one opening tag for the same
thing less.

Also, a quick opinion based poll has been done in the PHP.earth
Facebook group [1] with ~96% in favour of the removal.

So, +1 for removing these and simplify things more. There are only two
tags really needed in PHP templating engines https://fb.com/groups/2204685680/permalink/10157687999015681/

Best regards.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] Unbundle ext/interbase

[Peter Kokot]

Hello,

On Fri, 22 Mar 2019 at 14:26, Kalle Sommer Nielsen  wrote:
>
> G'day internals
>
> I'd like to start the discussion for the future of the ext/interbase 
> extension:
> https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase
>
> The rationale for pushing this extension out of the core is mentioned
> in the RFC.
>
> Unless there is any serious issues raised here, then I will put this
> into voting on Monday 8th of April, noon EET (which is a good two and
> a half weeks away). The intended voting period is set for 2 weeks,
> meaning if voting proceeds, the pools will be closed around Monday
> 22th of April, noon EET.
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

I'm all in for helping out here with both users using this and
maintainers that need to worry about if this extension is even working
ok. However, just one quick thought. The deprecation usually means
that some functionality will cease to exist. And users usually expect
and consider removing deprecated usage from their code and move to
something else. Not that they will have an option to install it over
PECL in PHP 8.0... Is this ok approach for this case? Because with
this approach PHP is also saying quietly that PECL is a museum for
extensions and not a place for developing them further. I might be
completely wrong here though...
-- 
Peter Kokot

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

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

[Peter Kokot]

Hello,

On Thu, 21 Mar 2019 at 12:58, Dmitry Stogov  wrote:
>
> Hey,
>
> I'm starting the vote on JIT RFC.
>
>
>  https://wiki.php.net/rfc/jit<https://wiki.php.net/rfc/typed_properties_v2>
>
>
> The voting period is one week, until Thursday 28-03-2019 GMT.
>
>
> Since the initial announcement and following discussions, RFC was imprved and 
> implementation extended with support for Clang, Windows and ZTS builds.
> Please reread RFC carefully.
>
>
> Thanks. Dmitry.

+1 to both options. Having such feature in the PHP-7.4 is also good to
be able to check it out sooner (and to have some test base). With
having this in PHP 8.0 we will need to wait for more than a year to
check it out. I'm sure very little people will compile PHP 8.0-dev on
their own and install it to test that before the release. PHP 8.0.0
release could be also about removing deprecated functionality. This
approach is actually following semver https://semver.org, so that's
all good I think.

In any case if we will need to wait more than another year or not,
thank you for your great work. Thumbs up. :)

-- 
Peter Kokot

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

Re: [PHP-DEV] Deprecate short_open_tag ini directive? PHP internals

[Peter Kokot]

Hello,
On Sat, 16 Mar 2019 at 03:57, Morgan Breden  wrote:
>
> >If you want to go further, dropping the PHP tag altogether would be nice,
> since it would prevent context switching between PHP/HTML/JS/whatever.
> >That would force Wordpress to update their whole
> code base. >:{)>
>
> I wholeheartedly support this initiative but I do not see it going through
> without a lot of resistance. Using PHP itself as a templating engine is
> part of what makes it so "newbie friendly".

I think using PHP tags for templates and option to write code without
opening tag might go through also. After all, text files are simple.

Something on this was already being done and probably also discussed:
https://wiki.php.net/rfc/nophptags

On the other hand, shebangs will still be present in CLI scripts. For example:
#!/usr/bin/env php

-- 
Peter Kokot

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

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

[Peter Kokot]

Hello,

On Tue, 12 Mar 2019 at 17:57, Johannes Schlüter  wrote:
>
> On Di, 2019-03-12 at 15:53 +, Rowan Collins wrote:
> > On Tue, 12 Mar 2019 at 13:28, G. P. B. 
> > wrote:
> >
> > >
> > > I was more going along the lines of removing short tags altogether
> > > with the
> > > ini setting as they are not available out of the box except if you
> > > use a
> > > special compile flag.
> > >
> >
> > I don't really follow this reasoning: if we removed every feature
> > which wasn't enabled out of the box, we wouldn't need an INI file at
> > all.
>
> Which would be good - as all those things make writing portable code
> harder.
>
>$ echo '' | php
>
> Is a valid program, which will behave vastly different based on the ini
> setting.
>
> Of course for some things having a config is good (error levels
> arguably, extension loading, ...) but for the raw language syntax and
> behavior not so.
>
> johannes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

In reality if developer wants to write "portable" and proper PHP code,
no one actually should use these short tags anymore. If they are still
used somewhere as part of some legacy code, they won't work on
majority of PHP installations anymore because the mostly have these
turned off today in the php.ini files. So, the question here is more
why supporting a feature that no one should use anymore...

-- 
Peter Kokot

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

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

[Peter Kokot]

On Tue, 12 Mar 2019 at 12:15, Alexandru Pătrănescu  wrote:
>
> Hi,
>
> I guess that `short_open_tag` ini settings can be deprecated/removed.
> But that would mean that short open tags will be always available, not that
> it will be removed.
>
> Regards,
> Alex

Oh, the main idea is to remove the ini directive which will make the
short tags by default then on? So the currently not enabled short tags
will be again enabled by default?

>From what I understand here, probably deprecation is referring also to
the short tags themselves in favour of the http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate short_open_tag ini directive?

[Peter Kokot]

Hello,
On Tue, 12 Mar 2019 at 10:51, Rowan Collins  wrote:
>
> On Mon, 11 Mar 2019 at 20:06, G. P. B.  wrote:
>
> > From my understanding, the ` > so maybe we should deprecate PHP's short tag altogether?
> >
>
>
> I think when that's been proposed in the past, people have said they like
> it for use in simple templates, often along with the "alternative control
> structures", e.g.:
>
> 
> quantity > 1 ): ?>description; ?> endif; ?>
> 
>
> I couldn't find any discussions for a few years, though, so it's possible
> opinions have changed.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]

PHP based template engines today most likely use only http://www.php.net/unsub.php

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

[Peter Kokot]

Hello,
On Wed, 6 Mar 2019 at 15:31, Joe Watkins  wrote:
>
> Hi all,
>
> It would be nice to hear from Peter , do you want to take on this role ?
>
> You would have my vote, obviously, but we like people to volunteer, it's
> not a small or short commitment.
>
> Cheers
> Joe
>
> On Wed, 6 Mar 2019 at 10:39, Kalle Sommer Nielsen  wrote:
>
> > Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov :
> > >
> > > On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann 
> > wrote:
> > >
> > > > Am 06.03.2019 um 01:18 schrieb Gabriel Caruso:
> > > > > I'd like to suggest Peter Kokot for this role.
> > > >
> > > > Seconded.
> > > >
> > >
> > > Thirded.
> >
> > Fourthed.
> >
> >
> >
> > --
> > regards,
> >
> > Kalle Sommer Nielsen
> > ka...@php.net
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >

First of all, thank you for the nomination and suggestion. Yes, of
course, I'd be honoured to do that part. Overall, it's no secret I
still have a lot of catching up to do as far as PHP core is concerned,
but for the PHP 7.4 timeframe I can do that and will do my best to
provide quality releases on the set dates. If you think that I'm the
correct person for the PHP 7.4 release manager role already, let's do
it...

I also wanted to say that the quality level of the current PHP 7.2 and
7.3 release managers is really outstanding. I'll do my best to catch
such level.

Thank you and have a nice day forward from my side.

-- 
Peter Kokot

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

Re: [PHP-DEV] print with newline

[Peter Kokot]

Hello,
On Mon, 4 Mar 2019 at 03:10, Steven Penny  wrote:
>
> On Mon, 04 Mar 2019 01:58:35, Stanislav Malyshev wrote:
> > It does not matter what you did before. It's not a "who spit on whom
> > first" discussion in a kindergarten. It's "you don't use this kind of
> > language here, period" discussion on this list. If you can't abide by
> > that, please use some other list. That's it.
>
> again, wrong. this list *is* kindergarten, as even PHP devs treat it that way,
> as ive demonstrated.
>
> if you wish to disregard the evidence i provided of that, its your business.
> same as if you decide to ban me. i would rather you not, but frankly at this
> point it doesnt seem like a loss.
>
> cheers
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

With this level of arrogance I'm not sure anything would go through
even if you payed someone to add such a feature. At least I know that
I wouldn't put up with such client or a colleague for very long... If
you have put zero effort in investigating issue and how to proceed
with such a feature request/idea even after getting instructions how
to proceed things won't move in any direction unless someone makes a
function for this. In open source world a lot of more adjustments is
needed. After more respect to one another will be shown, maybe we can
move on to discussing what is the better way to output a string and a
newline character included by default.

Now, interesting is that in bash and some langs (where the main
environment is CLI), there is by default newline echoed. In PHP and
other languages there isn't. Changing default functionality of echo in
PHP is like changing left-hand traffic countries to use right-hand
traffic. A new function name would be needed for that. You can start
with creating an extension for this... But with this level of
communication? Hm...
-- 
Peter Kokot

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

Re: [PHP-DEV] Re: phpenmod/phpdismod

[Peter Kokot]

On Mon, 18 Feb 2019, 23:39 Legale.legale  I have made super simple OS independent phpenmod.
>
> Https://github.com/legale/phpenmod
> On Feb 18, 2019 23:31, Gabriel Ostrolucky  wrote:
> >
> > I'm fan of this idea. I miss this in any other non-debian distro.
> > What nobody mentioned yet, similar script (dockerphp-ext-enable)
> > is used in PHP docker images. You can check them out at
> >
> https://github.com/docker-library/php/blob/master/7.3/alpine3.9/cli/docker-php-ext-enable
> >
> > However, enabling extensions in PHP via CLI is easy.
> > It's just php -dextension=extension.so. What isn't easy, is DISABLING
> them.
> >
> > This is very important to do when you have profiling/debugging
> extensions
> > like xdebug enabled.
> >
> > Currently, PHP community needs to do workaround gymnastics because of
> this
> > missing functionality. Check
> >
> https://stackoverflow.com/questions/31083195/disabling-xdebug-when-running-composer
> > and xdebug-handler created as a result
> >
> https://github.com/composer/xdebug-handler/blob/master/src/XdebugHandler.php
> >
> > Now, authors of CLI tools ship this xdebug-handler and unload it by
> default.
> > This makes their software faster by default, but all the CLI tool
> authors
> > must depend on this. And users are less aware of what's going on.
> >
> > If you are a consumer and your CLI tool does not depend on it,
> > you are out of luck, back to editing .ini files by hand - or
> > wondering why is the tool slow or even abandoning it because of that.
> > If you are a consumer and want to debug your CLI tool using it,
> > you will spend some time figuring out why it doesn't work.
> >
> > I know I went little offtopic here, since this thread is mainly about
> script
> > which persists these settings, instead of just CLI switch, but I think
> this
> > was worth mentioning, as it complements it. IMO hard to edit ini files
> are
> > frustrating mainly because of lacking quick way for disabling
> extensions.
> > Having a CLI swith do not only ENABLE extension, but also DISABLE it,
> would
> > help a lot and shipping script for modifying ini files might be a lot
> smaller
> > necessity after that.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>

For more portability - systems suppory (Linuc, mac, bsd etc) and still no
Windows instead of the #!/bin/bash use the shebang #!/bin/sh

Also, this tool mostly is still tied to current Linux repositories and not
to a php built from sources... So that's another thing making it specific
to certain installation type.

I'd still say that the tool needed for PHP is renewed and completwly
rewritten pecl. Basically copy paste of current functionality in its
essense and adding more swag and user features. Something like that...

>

Re: [PHP-DEV] Re: Old branches

[Peter Kokot]

Hello,

On Fri, 10 Aug 2018 at 12:54, Christoph M. Becker  wrote:
>
> On 30.07.2018 at 10:35, Gabriel Caruso wrote:
>
> > Recently, while checking some branches, I’ve noticed that we have really
> > old branches out there in php-src:
> >
> > 15+ years old:
> >
> >- experimental/RETURN_REF
> >- experimetnal/RETURN_REF_PATCH
> >- experimental/pre_new_hash_func
> >- experimental/zts_stdc_scanners
> >- experimental/rand_redesign
> >- migration/EXPERIMENTAL
> >- experimental/namespaces
> >- migration/unlabaled-1.67.2
> >- experimental/ZendEngine2
> >- experimental/apache_hooks
> >- experimental/apache_hooks
> >- migration/unlabaled-1.3.2
> >
> > 10+ years old:
> >
> >- migration/unlabaled-1.29.2
> >- migration/INITIAL
> >- migration/sqlite-start
> >
> > Not even 5 years old, but no commit:
> >
> >- str_size_and_int64_56_backport
> >- native-tls
> >- zend-signal-zts
> >
> > Not even 2 years old, but no commit:
> >
> >- microseconds
> >
> >
> > Do we keep them for a reason, like history, or we should delete, remaining
> > just the versions branches?
>
> In my opinion, it would be sensible to delete all useless branches, i.e.
> those which are completely stale, or have no commit.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

+1 Yes, please...

For a better overview of these:
https://github.com/php/php-src/branches/stale?page=12

-- 
Peter Kokot

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

Re: [PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

[Peter Kokot]

On Thu, 7 Feb 2019 at 18:01, Peter Kokot  wrote:
>
> Hello,
>
> On Thu, 7 Feb 2019, 16:52 Christoph M. Becker >
>> On 07.02.2019 at 16:14, Sjon Hortensius wrote:
>>
>> > On Wed, Feb 6, 2019 at 4:14 PM Ben Ramsey  wrote:
>> >
>> >>> On Feb 6, 2019, at 01:22, Peter Kokot  wrote:
>> >>> I can help sort this mess. A separate fork out of the php/php-src was
>> >>> not such a good idea.
>> >>
>> >> Sorry. I made many poor decisions around how I managed that entire event.
>> >> It’s my own personal Fyre Festival. :-(
>> >>
>> >> I’m happy to help in any way I can to get these ready to merge into
>> >> php-src. Let me know how I can help.
>> >
>> > anyone with access to the php-src git repo should be able to merge them
>> > pretty easily; it's a matter of running:
>> >
>> > curl -s '
>> > https://github.com/phpcommunity/phptestfest-php-src/pulls?page=1&q=is%3Apr+is%3Aopen+review%3Aapproved'|grep
>> > -Po '(?<=https://patch-diff.githubusercontent.com/raw/phpcommunity/phptestfest-php-src/pull/$id.patch|git
>> > am
>> > done
>> >
>> > and increase the page-number in the first URL to includes pages 2 & 3 as
>> > well. Run this in your checkout (possibly on a branch) and push that to
>> > github
>>
>> It seems to me that the tests should be reviewed (again).  The first one
>> I've seen[1], should be removed, since it tests general ZPP behavior,
>> and we're in the process to remove such tests generally[2].
>>
>> [1]
>> <https://github.com/phpcommunity/phptestfest-php-src/pull/155/files#diff-33e85609b0c12ee2d4b1c5f6190fdfa4>
>> [2] <https://github.com/php/php-src/pull/3783>
>>
>> --
>> Christoph M. Becker
>
>
> Hello, thanks for the info. Yes, the suggested script might seem like this 
> can be done in a simple way. However, I have no idea in what state the pull 
> requests at the forked repository are so I suggest we start opening separate 
> pull requests one by one to target PHP 7.4 branch. So overall, ~139 pull 
> requests. With 1-5 per day, we can have this fixed in a month to several 
> months or so. If more people can help opening pull requests, so much faster 
> this can be done.
>
> Fetching remote branch from another fork is quite easy:
> git checkout -b patch-1 upstream/PHP-7.4
> wget https://github.com/phpcommunity/phptestfest-php-src/pull/1.patch
> git am -3 1.patch
> # recheck commits, rebase, fix conflicts etc
> git push origin patch-1
> # Open pull request to recheck and merge into PHP-7.4 and master.
>
> Example:
> https://github.com/php/php-src/pull/3802
>
> --
> Peter Kokot

Additionally, majority of the pull requests there introduces a new
test file. Which means that merging is simpler compared to pull
requests where existing files are changed. Also, ~50% of the pull
requests are already approved thanks to @krakjoe [1] (filtering that
might help more).

[1] 
https://github.com/phpcommunity/phptestfest-php-src/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved


--
Peter Kokot

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

Re: [PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

[Peter Kokot]

Hello,

On Thu, 7 Feb 2019, 16:52 Christoph M. Becker  On 07.02.2019 at 16:14, Sjon Hortensius wrote:
>
> > On Wed, Feb 6, 2019 at 4:14 PM Ben Ramsey  wrote:
> >
> >>> On Feb 6, 2019, at 01:22, Peter Kokot  wrote:
> >>> I can help sort this mess. A separate fork out of the php/php-src was
> >>> not such a good idea.
> >>
> >> Sorry. I made many poor decisions around how I managed that entire
> event.
> >> It’s my own personal Fyre Festival. :-(
> >>
> >> I’m happy to help in any way I can to get these ready to merge into
> >> php-src. Let me know how I can help.
> >
> > anyone with access to the php-src git repo should be able to merge them
> > pretty easily; it's a matter of running:
> >
> > curl -s '
> >
> https://github.com/phpcommunity/phptestfest-php-src/pulls?page=1&q=is%3Apr+is%3Aopen+review%3Aapproved'|grep
> <https://github.com/phpcommunity/phptestfest-php-src/pulls?page=1&q=is%3Apr+is%3Aopen+review%3Aapproved'%7Cgrep>
> > -Po '(?<=https://patch-diff.githubusercontent.com/raw/phpcommunity/phptestfest-php-src/pull/$id.patch|git
> > am
> > done
> >
> > and increase the page-number in the first URL to includes pages 2 & 3 as
> > well. Run this in your checkout (possibly on a branch) and push that to
> > github
>
> It seems to me that the tests should be reviewed (again).  The first one
> I've seen[1], should be removed, since it tests general ZPP behavior,
> and we're in the process to remove such tests generally[2].
>
> [1]
> <
> https://github.com/phpcommunity/phptestfest-php-src/pull/155/files#diff-33e85609b0c12ee2d4b1c5f6190fdfa4
> >
> [2] <https://github.com/php/php-src/pull/3783>
>
> --
> Christoph M. Becker
>

Hello, thanks for the info. Yes, the suggested script might seem like this
can be done in a simple way. However, I have no idea in what state the pull
requests at the forked repository are so I suggest we start opening
separate pull requests one by one to target PHP 7.4 branch. So overall,
~139 pull requests. With 1-5 per day, we can have this fixed in a month to
several months or so. If more people can help opening pull requests, so
much faster this can be done.

Fetching remote branch from another fork is quite easy:
git checkout -b patch-1 upstream/PHP-7.4
wget https://github.com/phpcommunity/phptestfest-php-src/pull/1.patch
git am -3 1.patch
# recheck commits, rebase, fix conflicts etc
git push origin patch-1
# Open pull request to recheck and merge into PHP-7.4 and master.

Example:
https://github.com/php/php-src/pull/3802

--
Peter Kokot

>

Re: [PHP-DEV] 2016 TestFest, did the tests written then ever get merged?

[Peter Kokot]

Hello,

On Wed, 6 Feb 2019 at 08:13, Mark Baker  wrote:
>
> Looking at the Voting Eligibility discussion going on at the moment.
>
> I, like many others, participated in the last testfest 18 months or so
> ago. Did the results from that ever get merged? Or have they simply been
> discarded or forgotten? If merged, they certainly don't show up in the
> contributions list posted aganst the Workflow and Voting RFC Eligibility
> list: yet all those who participated in the testfest care about the
> language enough to get involved

No, they didn't. And longer we wait more file differences and "merge"
conflicts will happen.

I'd suggest to start adding one by one those that are accepted and
confirmed [1].

I can help sort this mess. A separate fork out of the php/php-src was
not such a good idea.

Important thing is also that the author is recognised in the commit
log properly and credits section is added as a recognition for the
volunteers (as noted in the php test fest instructions and all).

Let me know when we start adding those. Have a nice day.

[1] https://github.com/phpcommunity/phptestfest-php-src/pulls


-- 
Peter Kokot

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

Re: [PHP-DEV] 回复： [PHP-DEV] New website for the PHP project

[Peter Kokot]

Hello,

On Wed, 6 Feb 2019 at 01:37, 苏晞 <2823324...@qq.com> wrote:
>
> What the hell are you fucking talk about ,beaches -- 原始邮件 
> --

If I'd run this mailing list, you'd get a several weeks to months mute
now. But luckily that's not the case.

Read the mailing list rules [1] please. The tone and the quality of it
that is sent to these public channels is what makes the discussion
atmosphere and also younger generations learn from such low quality
responses. Keep this in your mind before sending emails or messages.

Thank you.

[1] https://github.com/php/php-src/blob/master/README.MAILINGLIST_RULES

-- 
Peter Kokot

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

Re: [PHP-DEV] Simplify license headers

[Peter Kokot]

On Mon, 4 Feb 2019, 02:32 Peter Kokot  On Wed, 30 Jan 2019 at 13:57, Derick Rethans  wrote:
> >
> > On Mon, 28 Jan 2019, Zeev Suraski wrote:
> >
> > >
> > > > I would like to make two changes to this header:
> > > >
> > > > 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity
> of updating this for
> > > > new major versions. I don't think the version information here is
> particularly useful to
> > > > anybody.
> > >
> > > I don't mind that much, but I don't see any issue with keeping it the
> way it is either.  It does look nicer the way it is now IMHO, and the cost
> associated with changing it twice a decade is, well, not very substantial.
> > >
> > > > 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart
> from requiring a
> > > > yearly update, this line is actually complete misinformation,
> because the PHP group
> > > > does *not* hold the copyright for the PHP source code. This would
> require a copyright
> > > > assignment agreement on behalf of all contributors, which we do not
> collect.
> > > >
> > > > We could also just drop the header entirely, I'm just proposing
> these two changes as
> > > > the path of least resistance towards getting the "annoying" parts
> removed.
> > >
> > > I'm no lawyer, but I do believe a case can be made for claiming that a
> > > person putting code into files with the header 'Copyright (c) XYZ', is
> > > in fact implicitly assigning copyright to XYZ.  So while it's not as
> > > strong as an explicit copyright assignment, and while it was never
> > > tested in court (and hopefully never will be) - I do see value in
> > > keeping it.  I certainly don't see a reason to change it after 20
> > > years where it didn't seem to bother anybody, unless there's a strong
> > > reason to do that, which currently I don't see.
> >
> > It could be changed to "1997-present" though, in which case it doesn't
> > need updating once a year (and messing up history in VCS).
> >
> > cheers,
> > Derick
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> Hello,
>
> I've prepared quick pull request [1] that fixes the missed headers in
> source code files and additionally bumps or changes the year range on
> other places.
>
> Questions:
>
> 1.) What should "php -v" output regarding copyrights and year ranges?
> 2.) What should "man php" include under the COPYRIGHT section
> regarding the year ranges?
> 3.) Similarly, should there be a common pattern for places like
> phpinfo() output?
>
> Thanks.
>
> [1] https://github.com/php/php-src/pull/3791
>
> --
> Peter Kokot
>

The pull request with a quickfix [1] to sync the year ranges will be merged
this weekend if everyone's ok with this... So now, only the LICENSE file
optionally gets bumped the year ranges and that simplifies managing files
significantly for the better. Thank you.

[1] https://github.com/php/php-src/pull/3791

>

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[Peter Kokot]

re with some advices and all.

>From what I've learned so far with the PHP sites: The websites overall
are very different from one another and some are actually very
complex. The pecl.php.net, bugs.php.net, and the main php.net site are
probably the most complex ones and all written in PHP vanilla way.
After long discussions (regarding the bugs.php.net site), pecl and
bugs sites now include optional Composer for local installation of
some dependencies such as PHPunit, generating fixtures, etc. (not on
production but for local development). So, they are actually going in
the direction of a more modern development. There are also some parts
of php sites that aren't available on GitHub and can't be properly
collaborated on yet (request to make a GH mirror has been submitted).

PECL and bugs sites have received quite a few, very strategic and
future prone changes recently with such step in mind also but it's a
long way to go. Not using some PHP framework for a reason of not
endorsing a framework is actually a really big challenge, but I guess
so it should be and we need to reinvent some required parts on the way
to make this happen. Deployment+production need also some refreshments
but it's a very challenging step from what I understand. For example,
to have this up and running, doing a remake, and doing systems
improvements at the same time.

Few quick suggestions:
- Let's keep the approximate wireframes of the websites as are.
- Let's make a central place for this discussion i.e. the webmaster mailing list
- Let's avoid too big tasks that require a fork + branch checkout +
tons of very difficult and time consuming design/infrastructure/app
changes and then opening a discussion on the webmaster mailing list to
even start considering it. We need to start giving hints and make
decisions before that step if this can be done on time.
- *.php.net sites under one roof maybe sound useful but separate
"services" (as is now) is IMHO a better way into this probably because
different servers, databases, usage cases are present. If one site
fails, others still work (in many cases). Many *.php.net sites
otherwise also use a common repository for a theme [1]. And some are
just too different with established practices.
- https://php.net/community is in my opinion a bit problematic concept
for PHP. PHP can trust its community and ecosystem around it. Mailing
lists, bugs, GitHub and such places work quite ok, but infrastructure
behind probably need a boost.


[1] https://github.com/php/web-shared



--
Peter Kokot

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

Re: [PHP-DEV] Simplify license headers

[Peter Kokot]

On Wed, 30 Jan 2019 at 13:57, Derick Rethans  wrote:
>
> On Mon, 28 Jan 2019, Zeev Suraski wrote:
>
> >
> > > I would like to make two changes to this header:
> > >
> > > 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity of 
> > > updating this for
> > > new major versions. I don't think the version information here is 
> > > particularly useful to
> > > anybody.
> >
> > I don't mind that much, but I don't see any issue with keeping it the way 
> > it is either.  It does look nicer the way it is now IMHO, and the cost 
> > associated with changing it twice a decade is, well, not very substantial.
> >
> > > 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart from 
> > > requiring a
> > > yearly update, this line is actually complete misinformation, because the 
> > > PHP group
> > > does *not* hold the copyright for the PHP source code. This would require 
> > > a copyright
> > > assignment agreement on behalf of all contributors, which we do not 
> > > collect.
> > >
> > > We could also just drop the header entirely, I'm just proposing these two 
> > > changes as
> > > the path of least resistance towards getting the "annoying" parts removed.
> >
> > I'm no lawyer, but I do believe a case can be made for claiming that a
> > person putting code into files with the header 'Copyright (c) XYZ', is
> > in fact implicitly assigning copyright to XYZ.  So while it's not as
> > strong as an explicit copyright assignment, and while it was never
> > tested in court (and hopefully never will be) - I do see value in
> > keeping it.  I certainly don't see a reason to change it after 20
> > years where it didn't seem to bother anybody, unless there's a strong
> > reason to do that, which currently I don't see.
>
> It could be changed to "1997-present" though, in which case it doesn't
> need updating once a year (and messing up history in VCS).
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

I've prepared quick pull request [1] that fixes the missed headers in
source code files and additionally bumps or changes the year range on
other places.

Questions:

1.) What should "php -v" output regarding copyrights and year ranges?
2.) What should "man php" include under the COPYRIGHT section
regarding the year ranges?
3.) Similarly, should there be a common pattern for places like
phpinfo() output?

Thanks.

[1] https://github.com/php/php-src/pull/3791

-- 
Peter Kokot

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

Re: [PHP-DEV] Re: RFC Weakrefs

[Peter Kokot]

Hello,

On Sun, 3 Feb 2019 at 20:00, Joe Watkins  wrote:
>
> Already taken care of :)
>
> On a side note, at what point do we remove stuff from the manual/pecl, the
> weakref is extension is dead, can't work with current versions of PHP, and
> there was never a stable release ?
>
> I'm not even sure we have a mechanism to delete stuff from pecl ... there's
> probably quite a lot of junk on there ...
>

Since PECL extensions is one whole compilation of extensions working
"together" and not falling into conflicts with names and similar
issues, PECL admins can simply set the package as "superseded by"
another package. For example:
https://pecl.php.net/package/date_time

If another "weakref" PHP extension will be developed elsewhere,
different naming can be picked for PECL or if that extension will
return to development, different approaches should be done probably
for it...

-- 
Peter Kokot

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

Re: [PHP-DEV] phpenmod/phpdismod

[Peter Kokot]

>> 3. Do you know where is the source code of these two scripts? When the
>> upstream script gets updated it would be then useful to copy/paste
>> changes into php-src. So the main development should be happening
>> upstream anyway. Meaning away from the PHP.
>
>
> I don't know what to say on that.

P.S. I've found sources at Debian mainstream:
https://sources.debian.org/src/php-defaults/69/php-helper/

Overall, I think this might be too Debian specific tool. PECL is
something that works in similar way. And it installs entire extension
from scratch together with compiling... PECL approach is something
that PHP should go into. Or, the more taboo way - Composer installable
extensions. There was some work done on that but it got stuck because
it is very large change and now nobody knows how to do that from that
step. Basically, a Composer plugin might be a better start with this.
Except that here we need to understand that PHP packages on Linux
distributions are already compiled and prepared for faster
installation, so installing extensions with PECL is a way different
approach compared to a more comfortable ways using
apt/yum/dnf/pacman/brew...

-- 
Peter Kokot

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

Re: [PHP-DEV] phpenmod/phpdismod

[Peter Kokot]

On Sat, 2 Feb 2019 at 20:24, Legale Legage  wrote:
>
> Hello, internal.
>
> I want to propose including to the bundle phpenmod/phpdismod scripts. These
> scripts are included to the standard deb/rpm packages. What do you think
> about including them to the bundle?
>
> If the idea is worthwhile, I will make the RFC.
>
> Saluti, Ruslan

1. Will it work also on Alpine Linux and MacOS? From what I see, the
title of these two POSIX shell scripts is "phpenmod - a PHP module
manager for Debian"
2. License MIT will cause any issues with bundling them in php-src?
3. Do you know where is the source code of these two scripts? When the
upstream script gets updated it would be then useful to copy/paste
changes into php-src. So the main development should be happening
upstream anyway. Meaning away from the PHP.

What these two scripts do is they enable "extensions" on Debian
installation. For example, phpenmod ftp
Some naming conventions name the PHP extensions (bcmath, openssl,
sodium...) also "modules". So, overall, nothing very simple to create
for all operating systems. Each Linux distribution has different
package repositories, locations to shared extension ini files, so that
is in this situation probably good to be left to 3rd party repository
maintainers or the Linux distro packages maintainers themselves.

Yes CLI tooling arsenal for more systems/devops oriented PHP world are
in need of improvements. There are many that lack handling extensions
(we were just discussing PECL for example in some other thread)...

-- 
Peter Kokot

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