On Nov 11 2024, at 12:03 am, Larry Garfield <la...@garfieldtech.com> wrote: > > First off, the obligatory "it was open for discussion for a month, and now > you mention this?"
I apologize for that, wasn't intentional. Unfortunately a whole pile of personal matters landed on my head between ... let's say October and November 6th that kept me from focusing on internals. As might be expected, the vote refocused my attention. I think this is worth discussing a bit more below,... TL;DR; I will at a minimum abstain from voting on this rather than vote "no" as my intent isn't to derail progress here. > For using, yes, full frameworks are not allowed for the reasons stated. > Components are fine, though, and if someone wanted to RFC an exception for > Symfony-based bugs.php.net, they can try. That's more permissive than the > current policy. > For documentation... it's no change from the current status quo. If your > concern is "zOMG, why can't we just tell people in the docs to use Symfony?", > it's because someone else will immediately respond with "zOMG, why can't we > just tell people to use Laravel instead?", and in a year or so someone will > probably say "zOMG why can't we just tell people to use Tempest?" And then > we'd have to argue if CodeIgnighter is something we want to even acknowledge > exists. Full frameworks are a very, very active market, and I *agree* that we > should try to avoid putting our thumb on the scales more than is necessary. > Though again, there's an RFC process for exceptions. Tangent, but FWIW I think this is something the PHP Foundation could help take on a bit, by creating a certification process a given framework can participate in. Any framework could apply, and all would be measured by the same reasonable standards.. then at least the PHP project could say "these frameworks have met this certification bar" which would be very helpful to people evaluating PHP as an option. I would gladly participate in drafting a rubric for community review if there was interest in that. > So really, contrary to what you're saying, this RFC improves precisely the > situation you're talking about in every way. Perhaps not as much as you would > like, but it still moves the needle closer to it. I really don't have the > stomach at the moment for litigating the "should we just go ahead and endorse > some framework" question (I'm on team-no anyway), so I deliberately avoided > that question when the main focus is to, as stated, let us mention Composer, > PHPUnit, and other staples that have nowhere near the healthy competition > that frameworks have. As I eluded to above, I am certainly not suggesting we endorse a single framework. I guess at the end of the day I've got a number of issues with the specifics of the language around how decisions are made in this doc, but I will concede that at least there is a document here that can be refined which is indeed a step forward. If you're interested some the concerns I have are (I'm focused on the maintainer bits below but I think they also largely apply to the marketing criteria as well): I don't think the "version 1.0" requirement is a good one, only because I strongly suspect it wouldn't take me very long to find a very reasonable library that for whatever reason is 0.8 or something... so now it can't be used, unless there is an RFC? I don't understand what the point of the "Explicitly approved" list is, if the point is any and all libraries which meet the acceptance criteria can be used without asking for permission then they are by default approved, right? Phrases like the library is a "de facto standard" is a really arbitrary, subjective criteria, ripe for misinterpretation or conflicting interpretation. As language it makes sense for the far edge cases and not much else IMO. I'm not suggesting that these alternatives be adopted right now... but off the top of my head I would offer these suggestions: The library should be focused on a specific need and provides clear, specific functionality needed by the PHP maintainers that would otherwise be unreasonable to implement and maintain themselves. The library should have an active developer community of at least 2 developers, and the library should have an currently active development history of at least 1 year. The library is provided under an Approved License On the marketing side I think we've got a long way to go, but that can be a discussion for later.. for now I'll just say that I have a lot of the same issues as the maintainer side regarding versioning / subjectiveness, etc. In my mind the marketing guidelines are way more important to the project than the maintainer ones: We can always resolve conflicts regarding this stuff and maintainers internally, but if we miss opportunities to tell potential users how PHP can solve their problem effectively we may never see them again. Anyway, like I said I'll abstain as my intention isn't to derail progress but I think this needs a lot more work as a set of guidelines. I'd be happy to help out with a second stab that if there is interest -- probably best off-list for a first draft? Coogle
