Re: [RFC] Policy on 3rd party code

Sent from my iPhone > On 6 Oct 2024, at 09:38, Larry Garfield <larry@garfieldtech.com> wrote: > > On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote: >>>> On 3 Oct 2024, at 01:48, 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 >>> >> >> 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 > > 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