Re: [PHP-DEV] [RFC] Policy on 3rd party code

2024-10-26 Thread Pierre Joye
Hello :)

On Sun, Oct 27, 2024 at 3:28 AM Jim Winstead  wrote:
>
> 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


Re: [PHP-DEV] [RFC] Policy on 3rd party code

2024-10-26 Thread Jim Winstead
On Thu, Oct 24, 2024, at 12:02 PM, Larry Garfield wrote:
> On Wed, Oct 2, 2024, at 1:36 PM, Larry Garfield 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*
>
> 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