Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up.
I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly.
https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.com
On Wed, Oct 2, 2024 at 3:38 PM Larry Garfield larry@garfieldtech.com
wrote:
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules, but I
think that's the right approach generally. It also includes a voting
mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind about
the concept in the first place. PHP is more than just php-src, and that's
a good thing. We need to catch up with that reality, while at the same
time maintaining a reasonable neutrality about projects Internals doesn't
manage directly.https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.com
Good writeup. Although I was more of a fan of Jim's RFC which just targets
the main issue of bringing up in the mailing list that PHP cannot use X
because "endorsement", this is also a good alternative.
My only problem with it is in the "discussion" section:
Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While Laravel
and Symfony are the market leaders in PHP frameworks, and WordPress
dominates the CMS-oid market, it is a highly dynamic market, with literally
dozens of players that have reasonable use. That makes listing them in the
documentation without “playing favorites” essentially impossible, and
therefore none should be listed by name. They should also not be used
directly to build any PHP tooling, again to avoid the appearance of
endorsement. However, it may make sense to list several of them in passing
in marketing material, explicitly noting that they are just some among many
options.
It's 2024. If the foundation is hiring developers to improve the language
across the board (internals, docs, website, processes, marketing,
visibility, etc), it makes no sense that these folks (or any volunteer for
that matter) be explicitly and unquestionably denied the opportunity or
conversation to modernize the system which PHP tooling is built upon. Its
understandable for historical reasons that frameworks would come and go,
which is why a lot of PHP systems from the 2005-2015 era usually are built
with an in-house framework. But at least in my little personal context,
in-house frameworks have proved themselves to be a nightmare for PHP
software engineers at large. A lot of these market leaders open source
frameworks are sustainable companies with a decade of proven stability,
reliability and efficiency. The sole principle behind a framework is to
facilitate work and this discussion point makes a clear statement that work
cannot be facilitated.
I am very opinionated on what is the best tool to help build PHP tooling,
but it seems pretty clear to me that any framework would be better than no
framework because the alternative is that a framework will be built
in-house and nobody in the world will have prior experience with that one.
--
Marco Deleu
Hey all
On Wed, Oct 2, 2024 at 3:38 PM Larry Garfield <larry@garfieldtech.com
mailto:larry@garfieldtech.com> wrote:Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up. I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly. https://wiki.php.net/rfc/third-party-code <https://wiki.php.net/rfc/third-party-code>; *Puts on trusty flame-retardant suit* -- Larry Garfield larry@garfieldtech.com <mailto:larry@garfieldtech.com>Good writeup. Although I was more of a fan of Jim's RFC which just
targets the main issue of bringing up in the mailing list that PHP
cannot use X because "endorsement", this is also a good alternative.My only problem with it is in the "discussion" section:
Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While Laravel and Symfony are the market leaders in PHP frameworks, and WordPress dominates the CMS-oid market, it is a highly dynamic market, with literally dozens of players that have reasonable use. That makes listing them in the documentation without “playing favorites” essentially impossible, and therefore none should be listed by name. They should also not be used directly to build any PHP tooling, again to avoid the appearance of endorsement. However, it may make sense to list several of them in passing in marketing material, explicitly noting that they are just some among many options.It's 2024. If the foundation is hiring developers to improve the
language across the board (internals, docs, website, processes,
marketing, visibility, etc), it makes no sense that these folks (or any
volunteer for that matter) be explicitly and unquestionably denied the
opportunity or conversation to modernize the system which PHP tooling is
built upon. Its understandable for historical reasons that frameworks
would come and go, which is why a lot of PHP systems from the 2005-2015
era usually are built with an in-house framework. But at least in my
little personal context, in-house frameworks have proved themselves to
be a nightmare for PHP software engineers at large. A lot of these
market leaders open source frameworks are sustainable companies with a
decade of proven stability, reliability and efficiency. The sole
principle behind a framework is to facilitate work and this discussion
point makes a clear statement that work cannot be facilitated.I am very opinionated on what is the best tool to help build PHP
tooling, but it seems pretty clear to me that any framework would be
better than no framework because the alternative is that a framework
will be built in-house and nobody in the world will have prior
experience with that one.
IMO the PHP website is more or less a bunch of static pages. There is
not really much interaction necessary. So having a framework might not
necessarily be The Thing.
I much rather see the new content to be provided via git in something
like DocBook or RestructuredText and then parsed by something like
PHPDocumentor based on a template into static websites.
But that's just my 0.02€
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas |
+---------------------------------------------------------------------+
| GPG-Key: https://hei.gl/keyandreasheiglorg |
+---------------------------------------------------------------------+
Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up.
I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly.
https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.comGood writeup. Although I was more of a fan of Jim's RFC which just targets the main issue of bringing up in the mailing list that PHP cannot use X because "endorsement", this is also a good alternative.
My only problem with it is in the "discussion" section:
Symfony, Laravel, Slim, Yii,WordPress, Drupal, TYPO3, etc. - While Laravel and Symfony are the market leaders in PHP frameworks, and WordPress dominates the CMS-oid market, it is a highly dynamic market, with literally dozens of players that have reasonable use. That makes listing them in the documentation without “playing favorites” essentially impossible, and therefore none should be listed by name. They should also not be used directly to build any PHP tooling, again to avoid the appearance of endorsement. However, it may make sense to list several of them in passing in marketing material, explicitly noting that they are just some among many options.
It's 2024. If the foundation is hiring developers to improve the language across the board (internals, docs, website, processes, marketing, visibility, etc), it makes no sense that these folks (or any volunteer for that matter) be explicitly and unquestionably denied the opportunity or conversation to modernize the system which PHP tooling is built upon.
To clarify, the PHP Foundation is not hiring developers to do "pure documentation work, PHP packages, websites, or translations" according to their recent call for applications for the next round of developers:
https://thephp.foundation/blog/2024/09/17/application-form-2025/
I bring this up because I don't want people to get the impression that this sort of decision making is up to the PHP Foundation, these are issues for the PHP community to decide and the RFC process is really the only accountable mechanism for that.
Jim
It's 2024. If the foundation is hiring developers to improve the language across the board (internals, docs, website, processes, marketing, visibility, etc),
As Jim has already stated, the Foundation is not hiring developers for any of the categories you mentioned other than internals, and build chains tools.
Maybe it should, but as far as I am aware, the choice not to is due to lack of sufficient funding.
Moreover, hiring for documentation is tricky, as one must be able to cross-reference the source code to verify the behaviour, on top of having technical writing skills, and working with our tooling.
it makes no sense that these folks (or any volunteer for that matter) be explicitly and unquestionably denied the opportunity or conversation to modernize the system which PHP tooling is built upon.
The only contention I have encountered with modernizing tooling has been about the use of Composer or PHPUnit for PhD.
Which would be resolved by this RFC.
As Andreas pointed out, the php.net websites are mostly static, and I don't see how a full-fledged framework would help us.
Especially as we have decommissioned some of the more clunky websites like bugsnet or gcov.
Maybe a micro-framework to handle php.net accounts and Documentation notes handling makes some sense.
As always in these sorts of discussions, people make out that the reason they do not contribute to a php.net related project is because of "XYZ".
Where XYZ can be anything.
And yet, we consistently get new contributors that get up to speed and help to modernize different codebases in the matter of weeks without issues,
and more importantly, without wanting to rewrite everything from scratch in their favourite thing that many of us have no idea how to use.
Best regards,
Gina P. Banyard
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules,
but I think that's the right approach generally. It also includes a
voting mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind
about the concept in the first place. PHP is more than just php-src,
and that's a good thing. We need to catch up with that reality, while
at the same time maintaining a reasonable neutrality about projects
Internals doesn't manage directly.https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
| The following packages are explicitly approved for use by this RFC, as
| they meet all of the criteria above.
|
| - Xdebug
That's not strictly true, as it doesn't have an "Approved License". It's
a nitpick, but Xdebug has "The Xdebug License"
(https://github.com/xdebug/xdebug/blob/master/LICENSE), which is the PHP
License 3.01, but with s/PHP/Xdebug.
I've been wanting to change that for ages, but it requires approval from
all contributors, and that's not going to happen easily.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules,
but I think that's the right approach generally. It also includes a
voting mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind
about the concept in the first place. PHP is more than just php-src,
and that's a good thing. We need to catch up with that reality, while
at the same time maintaining a reasonable neutrality about projects
Internals doesn't manage directly.https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
| The following packages are explicitly approved for use by this RFC, as
| they meet all of the criteria above.
|
| - XdebugThat's not strictly true, as it doesn't have an "Approved License". It's
a nitpick, but Xdebug has "The Xdebug License"
(https://github.com/xdebug/xdebug/blob/master/LICENSE), which is the PHP
License 3.01, but with s/PHP/Xdebug.I've been wanting to change that for ages, but it requires approval from
all contributors, and that's not going to happen easily.cheers,
Derick
Drat.
I suppose we could list that as an exception, like Docuwiki? The design is "RFC wins over heuristic", so if people vote to approve its mention, subtleties in the license don't matter.
--Larry Garfield
Hi
Am 2024-10-02 20:36, schrieb Larry Garfield:
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code.
Thank you. I'm not yet sure if I'm completely happy with it, but for me
it's already a much more agreeable proposal than Jim's for the reasons I
quoted from your mail.
Best regards
Tim Düsterhus
Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up.
I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly.
https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.com
Hi Larry,
Can you expand a bit more on this item from the exclusion list?
The library is a “full” application or framework.
To me that would mean anything that can be executed itself (be it a web app, a command like tool or daemon, etc.
But then you specifically say Composer and PHPUnit and Psalm and PHPstan are explicitly allowed... aren't all of them "full" applications, because they can be executed in and of themselves.
So, can you perhaps define what you mean by "full application" a little more clearly?
Cheers
Stephen
Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up.
I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly.
https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.comHi Larry,
Can you expand a bit more on this item from the exclusion list?
The library is a “full” application or framework.
To me that would mean anything that can be executed itself (be it a web
app, a command like tool or daemon, etc.But then you specifically say Composer and PHPUnit and Psalm and
PHPstan are explicitly allowed... aren't all of them "full"
applications, because they can be executed in and of themselves.So, can you perhaps define what you mean by "full application" a little
more clearly?Cheers
Stephen
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc.
While I feel that concern is sometimes over-blown, I do believe it is valid. Notably, the "big name communities" tend to also be complete, integrated solutions, and those also tend to be where there's more active competition. Eg, there's only one meaningful Yaml implementation the market, and two UUID libraries worth mentioning. But there's literally dozens of "frameworks" or "CMSes" to get mad at us.
So banning "full" frameworks is my attempt at steering clear of the appearance of that kind of favoritism. Showing favoritism for Composer or Xdebug is, well, there's no competition to complain. PHPUnit is technically not the only testing framework on the market, but it has north of 90% share (and is used internally by some of the few others). But showing favoritism between Drupal, Wordpress, TYPO3, Concrete5, and Joomla gets a lot dicier.
A full framework also makes maintenance potentially more challenging, as we it's a much larger external moving target than a UUID library that we could easily fork in a worst case scenario.
So... I don't really have a solid, clear definition of what constitutes a "full framework", because in the market, there isn't one. I'm sure someone could make a compelling argument that Slim isn't a full framework, for instance, although I don't think I'd agree with it.
It is inherently squishy, which is why these are intended as heuristics, not strict rules, and when it's unclear we can bring it to a vote via RFC, case by case.
I'm open to better ways to define what "full" means here if anyone has suggestions.
--Larry Garfield
Sent from my iPhone
On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote:
Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up.
I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly.
https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.comHi Larry,
Can you expand a bit more on this item from the exclusion list?
The library is a “full” application or framework.
To me that would mean anything that can be executed itself (be it a web
app, a command like tool or daemon, etc.But then you specifically say Composer and PHPUnit and Psalm and
PHPstan are explicitly allowed... aren't all of them "full"
applications, because they can be executed in and of themselves.So, can you perhaps define what you mean by "full application" a little
more clearly?Cheers
Stephen
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc.
While I feel that concern is sometimes over-blown, I do believe it is valid. Notably, the "big name communities" tend to also be complete, integrated solutions, and those also tend to be where there's more active competition. Eg, there's only one meaningful Yaml implementation the market, and two UUID libraries worth mentioning. But there's literally dozens of "frameworks" or "CMSes" to get mad at us.
So banning "full" frameworks is my attempt at steering clear of the appearance of that kind of favoritism. Showing favoritism for Composer or Xdebug is, well, there's no competition to complain. PHPUnit is technically not the only testing framework on the market, but it has north of 90% share (and is used internally by some of the few others). But showing favoritism between Drupal, Wordpress, TYPO3, Concrete5, and Joomla gets a lot dicier.
A full framework also makes maintenance potentially more challenging, as we it's a much larger external moving target than a UUID library that we could easily fork in a worst case scenario.
So... I don't really have a solid, clear definition of what constitutes a "full framework", because in the market, there isn't one. I'm sure someone could make a compelling argument that Slim isn't a full framework, for instance, although I don't think I'd agree with it.
It is inherently squishy, which is why these are intended as heuristics, not strict rules, and when it's unclear we can bring it to a vote via RFC, case by case.
I'm open to better ways to define what "full" means here if anyone has suggestions.
--Larry Garfield
Hi Larry,
Right I understand the motivation, it's just the phrasing that I think needs to be clarified.
From what you've said (which is kind of what I imagined you probably meant) I think it just needs to be clarified that the "full application" exclusion is about web applications, and doesn't applying to command line tooling/utilities.
Cheers
Stephen
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc.
While I feel that concern is sometimes over-blown, I do believe it is valid. Notably, the "big name communities" tend to also be complete, integrated solutions, and those also tend to be where there's more active competition. Eg, there's only one meaningful Yaml implementation the market, and two UUID libraries worth mentioning. But there's literally dozens of "frameworks" or "CMSes" to get mad at us.
So banning "full" frameworks is my attempt at steering clear of the appearance of that kind of favoritism. Showing favoritism for Composer or Xdebug is, well, there's no competition to complain. PHPUnit is technically not the only testing framework on the market, but it has north of 90% share (and is used internally by some of the few others). But showing favoritism between Drupal, Wordpress, TYPO3, Concrete5, and Joomla gets a lot dicier.
A full framework also makes maintenance potentially more challenging, as we it's a much larger external moving target than a UUID library that we could easily fork in a worst case scenario.
So... I don't really have a solid, clear definition of what constitutes a "full framework", because in the market, there isn't one. I'm sure someone could make a compelling argument that Slim isn't a full framework, for instance, although I don't think I'd agree with it.
It is inherently squishy, which is why these are intended as heuristics, not strict rules, and when it's unclear we can bring it to a vote via RFC, case by case.
I'm open to better ways to define what "full" means here if anyone has suggestions.
--Larry Garfield
Hi Larry,
Right I understand the motivation, it's just the phrasing that I think
needs to be clarified.From what you've said (which is kind of what I imagined you probably
meant) I think it just needs to be clarified that the "full
application" exclusion is about web applications, and doesn't
applying to command line tooling/utilities.Cheers
Stephen
Valid point. I've added another definition, and used it throughout:
Libraries refers to existing third party code packages or tools, either C extensions or PHP code, maintained by someone other than the PHP Internals team. It also includes command line utilities used primarily by a developer. It may also refer to non-profit PHP ecosystem organizations, such as the PHP Foundation or PHP-FIG.
Web Application refers to a “full” web framework that provides end-to-end web application capabilities, or an installable complete application. It does not refer to command line utilities used primarily by developers building applications.
(Libraries are OK, Web Applications are mostly not, except in marketing where we can mention them as long as we don't play favorites.)
--Larry Garfield
IMO the PHP website is more or less a bunch of static pages. There is not really much interaction necessary. So having a framework might not necessarily be The Thing.
You may be confusing cause with effect.
IOW, given that all the current infrastructure really supports are static pages — without a gargantuan effort to write and maintain a custom framework from scratch by unpaid volunteers — the resultant website can only realistically be static pages.
Frankly, I envision the PHP website could be so much more if developing and maintaining it were not a gargantuan effort. Like WordPress' plugin and theme repositories, PHP could have a database of all third party offerings — minus any objectively determined bad actors — and showcase to the world all that the extended PHP community has to offer.
Or, imagine a store where PHP could sell T-Shirts, plushies and more, all to fund more core development?
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc.
OR, we could change the current model and consider and another approach.
Instead of maintaining a website based on 1980s[1] technology which can give newer developers who are interested in modern developer tools the opinion that PHP is not for them, PHP could move to a model for its website where it embraces "Big names" and does so on merit.
What do I mean by "merit?"
Consider the potential of adopting a new approach where PHP puts out a call for RFPs to any and all who are interested in submitting a proposal to build and maintain a website for PHP for three (3) years at a time.
Interested stakeholders could join the PHP internal infrastructure mailing list and brainstormwhat is wanted tor the website and then prepare an RFP to put out for bid. Nominally we would do so without paying for the service — their benefit would be getting prominently featured as the developer and maintainer of the website — but we could ask organizations in the community like JetBrains to pitch into a pot that could go to the winner of the bid, if we want to.
Then we take proposals from the projects themselves, any agency, and/or any other organization that want to propose and we have the members of the PHP internal infrastructure mailing list create a short list of the proposers based on criteria such as if we think they will be able to maintain doing so for a 3 years as well as what they actually propose, and finally have all voting members would vote on it.
Why would we do it his way? Because this is how web development for organizations usually gets done today. I was involved in a agency project back in probably 2017 to build the website for the Agile Alliance (www.agilealliance.org). Certainly they had community members that could have built it but they chose instead to have it done by deciding what they wanted and they putting out an RFP. The result was they actually got the features they wanted in the near term instead of looking back 10 years or more thinking "When we can get around to it we can implement...whatever."
We would want to start this process well in advance to ensure enough people know about it and how time to submit a proposal — e.g. 18 months? — and that the RFP process for 3 years later would start a year after the site is launched. I can imagine that a lot of PHP-focused YouTubers would be all over promoting this.
Then the unpaid volunteers here need not be as highly skilled nor as burdened to maintain all the technical infrastructure and can instead focus on maintaining the actual content.
The concern for bias also gets thrown out the door because it is based more on merit, and the decision is widely distributed across all the voting stakeholders in PHP in a relatively transparent process. We could even say that any framework used for the last 3 years cannot be awarded the winning bid for the next 3 years to give more "big names" as shot at being the framework chosen.
There are tons of details that would need to be worked out, but as this is a wildly different approach from any the community has taken in the past — although as I said this is the common approach organizations take today to build and maintain websites — if it gets shot down by too many then no need to discuss the details any further.
-Mike
[1] I am being deliberately hyperbolic here for hopefully humorous effect. :-)
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc.
OR, we could change the current model and consider and another approach.
Instead of maintaining a website based on 1980s[1] technology which can
give newer developers who are interested in modern developer tools the
opinion that PHP is not for them, PHP could move to a model for its
website where it embraces "Big names" and does so on merit.
snip
While I am sympathetic to the idea of "if you want professional work done, just hire a professional," that is also vastly off topic for what we're discussing right now. The scope at the moment is much more "can we please tell people to use Composer? Can we please use PHPUnit for writing PhD and not feel guilty about it?" It's much more pedestrian and practical for the time being.
--Larry Garfield
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc.
OR, we could change the current model and consider and another approach.
Instead of maintaining a website based on 1980s[1] technology which can
give newer developers who are interested in modern developer tools the
opinion that PHP is not for them, PHP could move to a model for its
website where it embraces "Big names" and does so on merit.snip
While I am sympathetic to the idea of "if you want professional work done, just hire a professional," that is also vastly off topic for what we're discussing right now.
It is not off-topic, because it directly addresses the concern of mentioning or not mentioning web frameworks and not using them for internal use.
The scope at the moment is much more "can we please tell people to use Composer? Can we please use PHPUnit for writing PhD and not feel guilty about it?" It's much more pedestrian and practical for the time being.
However, yes, this point is completely valid, and can and should happen sooner and with or without what I suggested.
-Mike
IMO the PHP website is more or less a bunch of static pages. There is not really much interaction necessary. So having a framework might not necessarily be The Thing.
You may be confusing cause with effect.
IOW, given that all the current infrastructure really supports are
static pages — without a gargantuan effort to write and maintain a
custom framework from scratch by unpaid volunteers — the resultant
website can only realistically be static pages.Frankly, I envision the PHP website could be so much more if developing
and maintaining it were not a gargantuan effort. Like WordPress' plugin
and theme repositories, PHP could have a database of all third party
offerings — minus any objectively determined bad actors — and showcase
to the world all that the extended PHP community has to offer.
Developing and maintaining the PHP websites is far from a gargantuan effort, as evidenced by how it is currently (and has long been) maintained on a very ad-hoc basis by a very small number of volunteers with some work that is now sponsored by the PHP Foundation. (I believe that amounts to maybe the equivalent of one full-time person.)
I think a proposal for the PHP project taking on something like centralized databases of "all" third-party packages also needs to come up with a very good rationale as to why that will turn out differently than how PEAR and PECL did.
(And I think that "minus any objectively determined bad actors" is hand-waving away some extremely hard non-technical issues.)
Or, imagine a store where PHP could sell T-Shirts, plushies and more,
all to fund more core development?
I have a hard time imagining that this would ever be more than a rounding error compared to the sponsorships and individual contributions that the PHP Foundation currently relies on.
A number of people are concerned that if we use any of the "Big Names", it would be interpreted as an endorsement of that project. Eg, if we rebuilt the main website using Laravel, the Symfony folks would feel slighted. If we used Symfony, the Laravel folks would get rather cross. If we used Yii, the Slim folks would get upset. If we used Drupal, we'd get constant "well why not Wordpress?" questions. Etc.
OR, we could change the current model and consider and another approach.
Instead of maintaining a website based on 1980s[1] technology which can
give newer developers who are interested in modern developer tools the
opinion that PHP is not for them, PHP could move to a model for its
website where it embraces "Big names" and does so on merit.What do I mean by "merit?"
Consider the potential of adopting a new approach where PHP puts out a
call for RFPs to any and all who are interested in submitting a
proposal to build and maintain a website for PHP for three (3) years at
a time.Interested stakeholders could join the PHP internal infrastructure
mailing list and brainstormwhat is wanted tor the website and then
prepare an RFP to put out for bid. Nominally we would do so without
paying for the service — their benefit would be getting prominently
featured as the developer and maintainer of the website — but we could
ask organizations in the community like JetBrains to pitch into a pot
that could go to the winner of the bid, if we want to.Then we take proposals from the projects themselves, any agency, and/or
any other organization that want to propose and we have the members of
the PHP internal infrastructure mailing list create a short list of the
proposers based on criteria such as if we think they will be able to
maintain doing so for a 3 years as well as what they actually propose,
and finally have all voting members would vote on it.Why would we do it his way? Because this is how web development for
organizations usually gets done today. I was involved in a agency
project back in probably 2017 to build the website for the Agile
Alliance (www.agilealliance.org). Certainly they had community members
that could have built it but they chose instead to have it done by
deciding what they wanted and they putting out an RFP. The result was
they actually got the features they wanted in the near term instead of
looking back 10 years or more thinking "When we can get around to it we
can implement...whatever."We would want to start this process well in advance to ensure enough
people know about it and how time to submit a proposal — e.g. 18
months? — and that the RFP process for 3 years later would start a year
after the site is launched. I can imagine that a lot of PHP-focused
YouTubers would be all over promoting this.Then the unpaid volunteers here need not be as highly skilled nor as
burdened to maintain all the technical infrastructure and can instead
focus on maintaining the actual content.The concern for bias also gets thrown out the door because it is based
more on merit, and the decision is widely distributed across all the
voting stakeholders in PHP in a relatively transparent process. We
could even say that any framework used for the last 3 years cannot be
awarded the winning bid for the next 3 years to give more "big names"
as shot at being the framework chosen.There are tons of details that would need to be worked out, but as this
is a wildly different approach from any the community has taken in the
past — although as I said this is the common approach organizations
take today to build and maintain websites — if it gets shot down by too
many then no need to discuss the details any further.
Frankly, I find your proposal dubious because it assumes that there is some body of "interested stakeholders" who are going to be able to come to an agreement on an RFP that can then be used to enable a unbiased, merit-based selection by a vote of the voting members.
It assumes that somehow assembling all of the organizational infrastructure to enable outsourcing the technical infrastructure is solving the easy part of the problem.
It assumes that there is some need for non-static-pages with content that will somehow come pouring forth out of less-highly-skilled unpaid volunteers if only the technical infrastructure was taken care of for them.
What is currently blocking content that at least one unpaid volunteer* wants to contribute in a way that leverages the existing technical infrastructure is that there is vague, unwritten policy that we don't mention third-party tools in the PHP documentation, except for all of the third-party tools that we already mention in the PHP documentation.
Jim
- It's me, I'm the problem.
Or, imagine a store where PHP could sell T-Shirts, plushies and more,
all to fund more core development?I have a hard time imagining that this would ever be more than a rounding error compared to the sponsorships and individual contributions that the PHP Foundation currently relies on.
This is a rounding error that I really wish could appear on my desk. I'd happily purchase plushies, t-shirts, and (especially) coffee mugs. I can't really contribute monetarily in any meaningful way, but purchasing little items like these would be awesome, and I can't be the only one.
— Rob
What is currently blocking content that at least one unpaid volunteer* wants to contribute in a way that leverages the existing technical infrastructure is that there is vague, unwritten policy that we don't mention third-party tools in the PHP documentation, except for all of the third-party tools that we already mention in the PHP documentation.
I am totally with you on this, and I apologize on my part if anything about what I said made people view it as an either-or proposition.
Instead, I intended comments were intended to be viewed as "Yes, and..."
IOW, given that all the current infrastructure really supports are
static pages — without a gargantuan effort to write and maintain a
custom framework from scratch by unpaid volunteers — the resultant
website can only realistically be static pages.Developing and maintaining the PHP websites is far from a gargantuan effort, as evidenced by how it is currently (and has long been) maintained on a very ad-hoc basis by a very small number of volunteers with some work that is now sponsored by the PHP Foundation. (I believe that amounts to maybe the equivalent of one full-time person.)
What I was thinking when I spoke of a "gargantuan effort" was if a team were to try to duplicate the functionality of a modern website vs. just maintaining the aging and minimal website that is currently php.net http://php.net/.
I think a proposal for the PHP project taking on something like centralized databases of "all" third-party packages also needs to come up with a very good rationale as to why that will turn out differently than how PEAR and PECL did.
That rationale is an easy one.
-
First, both PEAR and PECL are package managers. I was proposing a directory. Directories are an order of magnitude easier to manage than a package manager.
-
PECL was an extremely high bar as it was a package needed to be written in C, so we should just ignore that one.
-
PEAR had huge friction because (from what I understand) it required approval from members of the PEAR Group to be included.
Let's instead compare to examples that turned out very different from PEAR and PECL, and although are arguable also package managers it is their directory aspect that I am focusing on and that IMO has been a significant reason for their success:
- https://packagist.org/ https://packagist.org/
- https://wordpress.org/plugins/ https://wordpress.org/plugins/
- https://www.drupal.org/project/project_module https://www.drupal.org/project/project_module
The reason those three have been far more successful has a large amount to do with the fact that the directory is managed by all the individuals in the community with solutions to showcase and and not a small group of overworked and underpaid individuals, and especially not having gatekeepers who must scan everything and who have subjective approval for inclusion.
And ensuring against bad actors have obviously been effectively managed by these other projects.
Given all those factors I do not see a strong argument to compare the experience with PECL and PAIR to the idea of php.net http://php.net/ hosting a directory of 3rd party solutions.
(And I think that "minus any objectively determined bad actors" is hand-waving away some extremely hard non-technical issues.)
While I would admit there may be some hand waving there, but to claim something is "extremely hard" without examples as a justification for not doing it is even more hand-wavy. Care to delineate at least of few of those extremely hard non-technical issues you envision to see if they are indeed extremely hard?
Or, imagine a store where PHP could sell T-Shirts, plushies and more,
all to fund more core development?I have a hard time imagining that this would ever be more than a rounding error compared to the sponsorships and individual contributions that the PHP Foundation currently relies on.
Maybe, maybe not.
But that perspective obscures the point I was trying to make. It is entirely possible that soliciting an RFP for a website that could also help generate revenue would present the community with ideas that nobody here has even considered.
One this is for absolutely certain, though. Keeping the website as-is will certainly not generate any additional revenue.
For me I would rather bet on the potential for innovation than bet against it.
Frankly, I find your proposal dubious because it assumes that there is some body of "interested stakeholders" who are going to be able to come to an agreement on an RFP that can then be used to enable a unbiased, merit-based selection by a vote of the voting members.
Maybe. But there is find fault then it is to find a working solution.
What I was asking people to consider is "Would we want this?" If the answer is yes, they we can discuss those things you claim to be dubious to see if there are solutions.
Again, if we don't look for solution we will absolutely never find any.
It assumes that somehow assembling all of the organizational infrastructure to enable outsourcing the technical infrastructure is solving the easy part of the problem.
It assumes that there is some need for non-static-pages with content that will somehow come pouring forth out of less-highly-skilled unpaid volunteers if only the technical infrastructure was taken care of for them.
No, that is not what it assumes.
What it assumes is that people can be rallied around an effort that is aspirational and the outcome can be an order of magnitude better result. Maintaining the existing website is not aspirational. Empowering the community to do so much more with the website could be aspirational.
So all I was asking was, "Is that a future people would like to see, or not?" If no, then never mind.
But if yes, why can we not explore how to make it happen?
-Mike
What is currently blocking content that at least one unpaid volunteer* wants to contribute in a way that leverages the existing technical infrastructure is that there is vague, unwritten policy that we don't mention third-party tools in the PHP documentation, except for all of the third-party tools that we already mention in the PHP documentation.
I am totally with you on this, and I apologize on my part if anything
about what I said made people view it as an either-or proposition.Instead, I intended comments were intended to be viewed as "Yes, and..."
snip
At this time, we're not looking for yes-ands in this thread. Please stop dragging it off topic into your own pet ideas. If you really want to push them, start new threads for them and leave this one alone.
--Larry Garfield
What is currently blocking content that at least one unpaid volunteer* wants to contribute in a way that leverages the existing technical infrastructure is that there is vague, unwritten policy that we don't mention third-party tools in the PHP documentation, except for all of the third-party tools that we already mention in the PHP documentation.
- It's me, I'm the problem.
You can add me to the list. :)
Christoph
So banning "full" frameworks is my attempt at steering clear of the appearance of that kind of favoritism. Showing favoritism for Composer or Xdebug is, well, there's no competition to complain. PHPUnit is technically not the only testing framework on the market, but it has north of 90% share (and is used internally by some of the few others). But showing favoritism between Drupal, Wordpress, TYPO3, Concrete5, and Joomla gets a lot dicier.
I think we are overloading the word "framework" here. I would suggest something along the lines of the following definitions:
A Web Application Platform: A fully-functional application written in PHP, often and perhaps exclusively with the purpose of building websites with little to no coding (excluding the notion of custom extensions or plugins to the application).
A PHP Framework: A collection of libraries bundled together that, by themselves, are not a functional application but rather as a whole provide the scaffolding to build an application on top of via code.
I personally can understand the argument against PHP proper seeming to endorse a Web Application Platform, but I think its entirely reasonable for PHP to internally use A PHP Framework if it happens to make the lives of people easier.
Coogle
Hi,
On Wed, Oct 2, 2024 at 7:38 PM Larry Garfield larry@garfieldtech.com
wrote:
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules, but I
think that's the right approach generally. It also includes a voting
mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind about
the concept in the first place. PHP is more than just php-src, and that's
a good thing. We need to catch up with that reality, while at the same
time maintaining a reasonable neutrality about projects Internals doesn't
manage directly.
I think it would be better to have just a light RFC introducing the basic
idea and create a PR against policies repo because that's where the wording
matters. We should be really voting on those PR's rather than create policy
RFC and then create PR that might have a different wording...
Regards
Jakub
Hi,
Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up.
I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly.
I think it would be better to have just a light RFC introducing the basic idea and create a PR against policies repo because that's where the wording matters. We should be really voting on those PR's rather than create policy RFC and then create PR that might have a different wording...
That would seem to be introducing a whole new process for making policy changes, because right now there is no voting process for PRs for any of the PHP organization repositories.
Maybe policy RFCs like this should have accompanying implementation PRs like many of the non-policy RFCs do, but I'm not sure that voting on PRs for policy changes makes any more sense than voting on PRs for code changes.
Jim
Hi,
On Wed, Oct 2, 2024 at 7:38 PM Larry Garfield larry@garfieldtech.com
wrote:Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules, but I
think that's the right approach generally. It also includes a voting
mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind about
the concept in the first place. PHP is more than just php-src, and that's
a good thing. We need to catch up with that reality, while at the same
time maintaining a reasonable neutrality about projects Internals doesn't
manage directly.https://wiki.php.net/rfc/third-party-code
I think it would be better to have just a light RFC introducing the basic
idea and create a PR against policies repo because that's where the wording
matters. We should be really voting on those PR's rather than create policy
RFC and then create PR that might have a different wording...That would seem to be introducing a whole new process for making policy
changes, because right now there is no voting process for PRs for any of
the PHP organization repositories.Maybe policy RFCs like this should have accompanying implementation PRs
like many of the non-policy RFCs do, but I'm not sure that voting on PRs
for policy changes makes any more sense than voting on PRs for code changes.
So there was already note about making changes to policy repo through RFC
in https://wiki.php.net/rfc/policy-repository . Specifically
Changes to the policy repository should only be made through a new RFC,
unless it is for fixing spelling mistakes or grammar.
So I think any changes to the policy should link PR to the policy repo in
the same way as we link implementation PR for other changes. What I wanted
to say is that the actual wording should be discussed in the PR but just
the main substance should be described in the RFC. The whole point of this
policy repo is that we don't have to look to every policy RFC but to have a
single place where all policies are defined.
Regards
Jakub
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules,
but I think that's the right approach generally. It also includes a
voting mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind about
the concept in the first place. PHP is more than just php-src, and
that's a good thing. We need to catch up with that reality, while at
the same time maintaining a reasonable neutrality about projects
Internals doesn't manage directly.https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
Some additional libraries that could probably be added to the list of pre-approved libraries for PHP tooling because they're already being used:
- michelf/php-markdown (used by main.php.net)
- phpmailer/phpmailer (used by main.php.net)
- squizlabs/php_codesniffer (used by news-web.php.net)
- symfony/dotenv (used by pecl.php.net)
- symfony/console (used by pecl.php.net)
- fzaninotto/faker (used by pecl.php.net)
- friendsofphp/php-cs-fixer (used by www.php.net)
The way that the "PHP documentation" section talks about third-party libraries feels strange, but there are also other third-party tools and services mentioned and that we may want to think about:
The documentation has a chapter on installing LiteSpeed which covers both the commercial version (LiteSpeed Web Server) and the open source version (OpenLiteSpeed Web Server). https://www.php.net/install.unix.litespeed
Can we add a section on Caddy that is similar to the ones for Apache and NGINX?
What about FrankenPHP?
The instructions for installing macOS via packages has an example for Brew but not for MacPorts or Fink. https://www.php.net/install.macosx.packages
There is a section in the Windows install docs that lists third-party packages but there's not even an example or explanation like there is for Brew on macOS: https://www.php.net/install.windows.tools
There is a chapter on installing PHP on cloud providers that only includes three providers: https://www.php.net/install.cloud
Could we add a section about Google Cloud?
Could we add a section about Oracle Cloud?
Could we add a section about STACKIT?
Could we add a section about Hetzner?
What about Laravel Cloud (when it launches)?
Jim
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules, but I
think that's the right approach generally. It also includes a voting
mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind about
the concept in the first place. PHP is more than just php-src, and that's
a good thing. We need to catch up with that reality, while at the same
time maintaining a reasonable neutrality about projects Internals doesn't
manage directly.https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.com
I remember a while ago a discussion about bundling composer with PHP by
default (and possibly dropping pear).
What ever happened with that?
As the first thing any dev does after setting up PHP, is install composer.
As this RFC points out, almost every project modern uses composer to manage
dependencies, and every Library, SDK and framework requires composer.
So i'd change this line in the RFC
We should use it, we should document it, we should promote it.
To
We should use it, we should document it, we should promote it, we should
bundle it!
As I mentioned, it is basically a requirement nowadays to work in PHP
unless you are doing something custom that doesnt require any dependencies,
but then, is that person planning to release it to the public?
I am of no opinion of weather php devs internally should use composer, i
have no skin in that game. But Documentation - Yes, Promotion - Yes, but
does it really need it? Bundle it - Yes!
Since Jim's RFC proposal was criticized for being too vague, I hereby offer a somewhat more prescriptive policy proposal on using 3rd party code. (With JIm's blessing.) It's still more heuristics than rules, but I think that's the right approach generally. It also includes a voting mechanism to resolve edge cases when they come up.
I'm sure we'll bikeshed it to death, but please keep an open mind about the concept in the first place. PHP is more than just php-src, and that's a good thing. We need to catch up with that reality, while at the same time maintaining a reasonable neutrality about projects Internals doesn't manage directly.
https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
--
Larry Garfield
larry@garfieldtech.comI remember a while ago a discussion about bundling composer with PHP by default (and possibly dropping pear).
What ever happened with that?
As the first thing any dev does after setting up PHP, is install composer. As this RFC points out, almost every project modern uses composer to manage dependencies, and every Library, SDK and framework requires composer.
So i'd change this line in the RFCWe should use it, we should document it, we should promote it.
To
We should use it, we should document it, we should promote it, we should bundle it!As I mentioned, it is basically a requirement nowadays to work in PHP unless you are doing something custom that doesnt require any dependencies, but then, is that person planning to release it to the public?
I am of no opinion of weather php devs internally should use composer, i have no skin in that game. But Documentation - Yes, Promotion - Yes, but does it really need it? Bundle it - Yes!
There is nothing stopping packagers from bundling composer. In fact, install-php-extensions (https://github.com/mlocati/docker-php-extension-installer) can do it via @composer.
Debian packagers can recommend it via “recommends” and I believe the default settings will install it.
The main issue is that composer is updated fairly regularly and most package maintainers don’t have the time to keep up with it.
— Rob
I remember a while ago a discussion about bundling composer with PHP by
default (and possibly dropping pear).
What ever happened with that?
As the first thing any dev does after setting up PHP, is install
composer. As this RFC points out, almost every project modern uses
composer to manage dependencies, and every Library, SDK and framework
requires composer.
So i'd change this line in the RFCWe should use it, we should document it, we should promote it.
To
We should use it, we should document it, we should promote it, we should bundle it!As I mentioned, it is basically a requirement nowadays to work in PHP
unless you are doing something custom that doesnt require any
dependencies, but then, is that person planning to release it to the
public?
I am of no opinion of weather php devs internally should use composer,
i have no skin in that game. But Documentation - Yes, Promotion - Yes,
but does it really need it? Bundle it - Yes!
Bundling Composer with PHP is an entirely different question with a host of additional concerns to consider, like whether the Composer maintainers would even want that. Let's please stay focused on the topic at hand.
--Larry Garfield
Bundling Composer with PHP is an entirely different question with a host of additional concerns to consider, like whether the Composer maintainers would even want that. Let's please stay focused on the topic at hand.
--Larry Garfield
I think the multiple deviations from the topic suggests the policy changes don’t go far enough. In contrast, I also think the people that wants bigger changes are more likely to not have a vote and have felt how much the PHP project makes it difficult to receive contributions.
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules,
but I think that's the right approach generally. It also includes a
voting mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind about
the concept in the first place. PHP is more than just php-src, and
that's a good thing. We need to catch up with that reality, while at
the same time maintaining a reasonable neutrality about projects
Internals doesn't manage directly.https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
An update here. I have converted the RFC into a PR against the policies repo. (Thanks to Derick for his help in dealing with RST format.)
https://github.com/php/policies/pull/10
It's essentially the same as the last RFC text, though I split up the approved lists to make it easier to add to in the future. I also added an exceptions mechanism for Dokuwiki.
The RFC itself has been updated to be basically just a placeholder stub for the PR. The vote will be basically "merge this PR? Y/N."
Absent any more feedback, I will call a vote on it in a week or so.
--Larry Garfield
Since Jim's RFC proposal was criticized for being too vague, I hereby
offer a somewhat more prescriptive policy proposal on using 3rd party
code. (With JIm's blessing.) It's still more heuristics than rules,
but I think that's the right approach generally. It also includes a
voting mechanism to resolve edge cases when they come up.I'm sure we'll bikeshed it to death, but please keep an open mind about
the concept in the first place. PHP is more than just php-src, and
that's a good thing. We need to catch up with that reality, while at
the same time maintaining a reasonable neutrality about projects
Internals doesn't manage directly.https://wiki.php.net/rfc/third-party-code
Puts on trusty flame-retardant suit
An update here. I have converted the RFC into a PR against the
policies repo. (Thanks to Derick for his help in dealing with RST
format.)https://github.com/php/policies/pull/10
It's essentially the same as the last RFC text, though I split up the
approved lists to make it easier to add to in the future. I also added
an exceptions mechanism for Dokuwiki.The RFC itself has been updated to be basically just a placeholder stub
for the PR. The vote will be basically "merge this PR? Y/N."Absent any more feedback, I will call a vote on it in a week or so.
There were more existing 3rd-party dependencies that should probably be added to the policy text:
https://news-web.php.net/php.internals/125769
Two I missed were JpGraph and Parsedown which are used by web-doc. (Currently by side-loading JpGraph and having an old copy of Parsedown committed to web-doc, I would hope to move those out as Composer dependencies if we decide to allow that.)
Jim
Hello :)
There were more existing 3rd-party dependencies that should probably be added to the policy text:
https://news-web.php.net/php.internals/125769
Two I missed were JpGraph and Parsedown which are used by web-doc. (Currently by side-loading JpGraph and having an old copy of Parsedown committed to web-doc, I would hope to move those out as Composer dependencies if we decide to allow that.)
Jim
First, I want to extend my gratitude to all who keep this effort
running, your efforts are truly appreciated and much needed! :)
I've been following this thread and, while I understand the historical
context and some of the off-topic discussions, I find myself a bit
puzzled.
Historically, the restrictions on what could be used for the php-web,
php-doc, and other codebases were primarily about ensuring that
mirrors could operate using a stock PHP setup without additional
dependencies like database servers. Over time, some services couldn't
adhere to these restrictions, leading to various exceptions. It is
important to note that php.net no longer has an official mirror
program (see https://www.php.net/mirroring.php).
Historically, the restrictions on what can be used for the php-web,
php-doc, etc code base at large was about the mirrors (, for any of
these services, could use it by using a stock PHP without anything
else, be database servers etc. Some services obviously could not do
it with these restrictions and 'exceptions' have appeared along the
way. php.net does not have an official mirror program anymore (see
https://www.php.net/mirroring.php), though mirrors still advertise
themselves at https://www.php.net/mirror.php
The principle that "php.net does not do promotional content" was, and
still is, about avoiding explicit promotions of specific companies,
products, or individuals. For example, all mirrors were listed in one
place, and links/ads/etc from our homepage were never allowed. This is
the context behind the stance of not promoting non-php.net entities.
Regarding the tools we use in php.net projects, we already leverage a
wide range of tools, services, and libraries, both PHP-based and
otherwise. These can be seen in our repositories and elsewhere. Given
that we no longer rely on a mirror network program per se, I don't see
the issue with relaxing some of these strict rules. Doing so could
make life easier and more enjoyable for maintainers, and likely
improve the codebase by reducing the "Not Invented Here" syndrome or
making things easier to maintain.
Composer, for instance, has always wanted to remain independent from
php.net, which is perfectly understandable. However, does this mean we
can't use it? That seems like an overreaction in today's PHP
development ecosystem. While it's true that anything can be done using
a stock PHP setup without dependencies, this approach has not been
ideal for many areas for quite some time. It is most certainly valid
as well for many other tools or libraries.
Last but not least, it might be a good thing (tm) to maintain a simple
list of the tools we use and their purposes. This wouldn't be
promotional but rather informative, helping everyone understand the
current state of our toolset, improving transparency.
best,
Pierre
@pierrejoye | http://www.libgd.org
There were more existing 3rd-party dependencies that should probably be
added to the policy text:https://news-web.php.net/php.internals/125769
Two I missed were JpGraph and Parsedown which are used by web-doc.
(Currently by side-loading JpGraph and having an old copy of Parsedown
committed to web-doc, I would hope to move those out as Composer
dependencies if we decide to allow that.)Jim
I have updated the pre-approved list to include everything we're currently using for PHP Tooling, and added a few of them to the other lists as well. (List both Psalm and PHPStan, list both CS-Fixer and CodeSniffer, etc.) For JPGraph, it looks like the original is abandoned and there's a zillion forks, so I listed the one that is by far most popular on Packagist.
Since folks may have opinions on these lists, I'll give it a few more days before calling the vote in case someone wants to weigh in.
The link again is: https://github.com/php/policies/pull/10
--Larry Garfield