Re: [RFC] Policy on 3rd party code

From: Date: Sat, 05 Oct 2024 17:30:52 +0000
Subject: Re: [RFC] Policy on 3rd party code
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-125752@lists.php.net to get a copy of this message
> 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

« previous php.internals (#125752) next »