Re: [RFC] Policy on 3rd party code

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