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

2024-10-31 Thread Larry Garfield
On Sat, Oct 26, 2024, at 3:24 PM, 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 sid

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

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'

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

2024-10-24 Thread Larry Garfield
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

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

2024-10-24 Thread Marco Aurélio Deleu
> On 24 Oct 2024, at 03:27, Larry Garfield wrote: > > Bundling Composer with PHP is an entirely different question with a host of > additional concerns to consider, like whether the Composer maintainers would > even want that. Let's please stay focused on the topic at hand. > > --Larry Garf

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

2024-10-24 Thread Rob Landers
On Thu, Oct 24, 2024, at 01:57, fennic log wrote: > > On Wed, 2 Oct 2024 at 19:37, 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 sti

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

2024-10-24 Thread Larry Garfield
On Wed, Oct 23, 2024, at 6:57 PM, fennic log wrote: > I remember a while ago a discussion about bundling composer with PHP by > default (and possibly dropping pear). > What ever happened with that? > As the first thing any dev does after setting up PHP, is install > composer. As this RFC points

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

2024-10-23 Thread fennic log
On Wed, 2 Oct 2024 at 19:37, 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

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

2024-10-17 Thread Christoph M. Becker
On 08.10.2024 at 01:31, Jim Winstead wrote: > What is currently blocking content that at least one unpaid volunteer* wants > to contribute in a way that leverages the existing technical infrastructure > is that there is vague, unwritten policy that we don't mention third-party > tools in the PH

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

2024-10-09 Thread Larry Garfield
On Tue, Oct 8, 2024, at 8:48 PM, Mike Schinkel wrote: >> On Oct 7, 2024, at 7:31 PM, Jim Winstead wrote: >> >> What is currently blocking content that at least one unpaid volunteer* wants >> to contribute in a way that leverages the existing technical infrastructure >> is that there is vague, u

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

2024-10-08 Thread Mike Schinkel
> On Oct 7, 2024, at 7:31 PM, Jim Winstead wrote: > > What is currently blocking content that at least one unpaid volunteer* wants > to contribute in a way that leverages the existing technical infrastructure > is that there is vague, unwritten policy that we don't mention third-party > tools

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

2024-10-08 Thread Jim Winstead
On Wed, Oct 2, 2024, at 11:36 AM, 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

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

2024-10-08 Thread Rob Landers
On Tue, Oct 8, 2024, at 01:31, Jim Winstead wrote: > On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel wrote: > > Or, imagine a store where PHP could sell T-Shirts, plushies and more, > > all to fund more core development? > > I have a hard time imagining that this would ever be more than a roundin

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

2024-10-08 Thread Jakub Zelenka
On Tue, Oct 8, 2024 at 12:20 AM Jim Winstead wrote: > On Mon, Oct 7, 2024, at 2:54 AM, Jakub Zelenka wrote: > > Hi, > > On Wed, Oct 2, 2024 at 7:38 PM Larry Garfield > wrote: > > Since Jim's RFC proposal was criticized for being too vague, I hereby > offer a somewhat more prescriptive policy pro

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

2024-10-07 Thread Jim Winstead
On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel wrote: >> On Oct 2, 2024, at 3:36 PM, Andreas Heigl wrote: >> IMO the PHP website is more or less a bunch of static pages. There is not >> really much interaction necessary. So having a framework might not >> necessarily be The Thing. > > You may b

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

2024-10-07 Thread Jim Winstead
On Mon, Oct 7, 2024, at 2:54 AM, Jakub Zelenka wrote: > Hi, > > On Wed, Oct 2, 2024 at 7:38 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.)

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

2024-10-07 Thread Jakub Zelenka
Hi, On Wed, Oct 2, 2024 at 7:38 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 th

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

2024-10-07 Thread John Coggeshall
> 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%

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

2024-10-06 Thread Mike Schinkel
> On Oct 7, 2024, at 1:39 AM, Larry Garfield wrote: > > On Sun, Oct 6, 2024, at 2:33 PM, Mike Schinkel wrote: > >>> On Oct 5, 2024, at 10:25 PM, Larry Garfield wrote: >>> >>> A number of people are concerned that if we use any of the "Big Names", it >>> would be interpreted as an endorseme

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

2024-10-06 Thread Larry Garfield
On Sun, Oct 6, 2024, at 2:33 PM, Mike Schinkel wrote: >> On Oct 5, 2024, at 10:25 PM, Larry Garfield wrote: >> >> 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 L

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

2024-10-06 Thread Mike Schinkel
> On Oct 2, 2024, at 3:36 PM, Andreas Heigl wrote: > IMO the PHP website is more or less a bunch of static pages. There is not > really much interaction necessary. So having a framework might not > necessarily be The Thing. You may be confusing cause with effect. IOW, given that all the curr

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

2024-10-06 Thread Larry Garfield
On Sat, Oct 5, 2024, at 11:27 PM, Stephen Reay wrote: >> 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 u

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

2024-10-05 Thread Stephen Reay
Sent from my iPhone > On 6 Oct 2024, at 09:38, Larry Garfield wrote: > > On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote: On 3 Oct 2024, at 01:48, Larry Garfield wrote: >>> >>> Since Jim's RFC proposal was criticized for being too vague, I hereby >>> offer a somewhat more presc

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

2024-10-05 Thread Larry Garfield
On Sat, Oct 5, 2024, at 12:30 PM, Stephen Reay wrote: >> On 3 Oct 2024, at 01:48, 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 st

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

2024-10-05 Thread Stephen Reay
> On 3 Oct 2024, at 01:48, 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

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

2024-10-04 Thread Larry Garfield
On Fri, Oct 4, 2024, at 6:22 AM, Derick Rethans wrote: > On Wed, 2 Oct 2024, 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

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

2024-10-04 Thread Tim Düsterhus
Hi Am 2024-10-02 20:36, schrieb Larry Garfield: 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. Thank you. I'm not yet sure if I'm completely happy with it, but for me it's already a much more a

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

2024-10-04 Thread Derick Rethans
On Wed, 2 Oct 2024, 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 approa

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

2024-10-03 Thread Gina P. Banyard
On Wed, Oct 2, 2024, at 12:17 PM, Deleu wrote: > It's 2024. If the foundation is hiring developers to improve the language > across the board (internals, docs, website, processes, marketing, visibility, > etc), As Jim has already stated, the Foundation is not hiring developers for any of the c

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

2024-10-02 Thread Jim Winstead
On Wed, Oct 2, 2024, at 12:17 PM, Deleu wrote: > On Wed, Oct 2, 2024 at 3:38 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 mor

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

2024-10-02 Thread Andreas Heigl
Hey all On 02.10.24 21:17, Deleu wrote: On Wed, Oct 2, 2024 at 3:38 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 J

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

2024-10-02 Thread Deleu
On Wed, Oct 2, 2024 at 3:38 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 rig