hi Rowan, A quick side-note, a reply that opens with at least a hello goes a long way. It costs nothing and it is the difference between a review and a brush off. We are not bots and don't talk to bots.
On Mon, Jul 20, 2026 at 6:54 PM Rowan Tommins [IMSoP] <[email protected]> wrote: > > On 20 July 2026 11:39:42 BST, Pierre Joye <[email protected]> wrote: > >On timing, the delay getting this posted wasn't from a lack of > >readiness, it was internal review process friction, a required PR > >approval that wasn't actually being handled in the PR itself, just > >assigned to a bot reviewer. I ended up merging it myself last week > >rather than wait longer on that. > > Can you clarify this point - what PR was this, and why did it need to be > merged before even announcing the RFC? I wonder why replying without actually reading the rfc and the linked PR you asked about here linked in the RFC? or is there a particular outcome expected? However, to answer your question, It was important tot: 1. validate full compatibility of the libgd update with current php on all platforms and supported features to date 2. it uses some "modern" C features, so a full blown validation on php CIs is a must have first 3. Actual additions to php are thin layers now added in this thread RFC. No more "business" logic in the binding itself but if needed to handle older external versions. In short, the PR validation runners are numerous and have many platforms, rules and analyzers that I don't have access to, or partially using them (asan f.e. but not all archs). It also went through a security audit, thanks to Volker for doing it :) So doing that part first was a quality and validation step and allowed the actual features addition RFC to focus on what it does, adding features. That being said, I am not sure we realize the state of affairs here. This is a PR and RFC that massively improves existing functions. Read: everything under the hood, aside from the new APIs, is fixes and improvements to what already exists. The new APIs themselves have zero impact on existing functionality. They prepare PHP 9 and bring a much more developer friendly way to do image operations. And the recurring answer, too many times, has been "policies" or "wiki syntax." This release is still in alpha. Whatever the plan is for the next beta, we're not at RC yet, and new approved features landing before RC is exactly what we've reasonably expected before these non pragmatic policies changes. I'm not asking to hold the release for this RFC. While I still think the existing schedule allows such additions to land. For the reasons explained above. And because what I've described above is wrong, on so many levels, and I fail to see how PHP reached this point of bureaucracy. Cheers, -- Pierre @pierrejoye
