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

Reply via email to