[PHP-DEV] Re: [PHP-DEV] Re: [PHP-DEV] Re: [PHP-DEV] Re: [PHP-DEV] [RFC] [DISCUSSION] ext/gd 2.4 — codec sync, Gd\* OOP API, 2D vector/canvas

On 21/07/2026 03:18, Pierre Joye wrote:
> 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.


Hi Pierre,

I apologise completely for this. I often forget to add a greeting when 
editing a reply, particularly on mobile. I definitely do not want to 
sound rude or inhuman, so I will try to remember to include this in future.


>> 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?


I worded it that way to make sure I didn't look in the wrong place and 
jump to the wrong conclusions. But the important part of the question 
was the "why", which you have answered below.


> 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.


That makes sense. I realise it's too late to say now, but it sounds like 
the RFC text could have been presented *in parallel* to that 
verification. That would have given more time for people to digest the 
new user-facing API, and suggest any changes without running as close to 
the feature freeze.

It's quite common for implementations not to be finalised even when an 
RFC is voted on, as long as changes don't impact what was agreed in the 
RFC. The policy that has been formalised explicitly allows for that to 
happen during the Beta period.


> 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."


I understand your frustration, and from what I've read, it looks like a 
really great addition to the language.

But I do think its important that new features are given the time and 
attention needed to refine small details. Names of new keywords or 
classes, signatures of new methods, etc, are generally very easy to 
change during an RFC discussion, but very hard to change once it's made 
it into a stable release.

On the other hand, it's useful to have a cut-off point for new features 
somewhere in the release process. If an RFC is in discussion close to 
that cut-off point, there's always going to be an awkward decision: do 
we cut off discussion because we're running out of time for the release, 
or do we push the feature back a year so we can have the proper discussion?

Although it feels like bureaucracy, having a pre-determined cut-off date 
can in theory make that decision easier: we don't have to debate for 
every RFC whether it's "small enough" or "important enough" to carry on 
discussing, we just have to ask "is it ready in time for the cut-off?"


> 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 sure how strictly it was previously enforced, but the release 
cycle update RFC from two years ago refers to the requirement for RFCs 
to be voted before beta (but not necessarily merged) as an existing 
policy: https://wiki.php.net/rfc/release_cycle_update

That RFC actually made that deadline later, because it shortened the 
overall timeline, moving the feature freeze from July to August; and 
thus the RFC discussion deadline from June to July.

Wherever that deadline falls, there will always be proposals which, for 
whatever reason, are written close to it. Naturally, the authors of 
those proposals will be frustrated at their change being held back until 
the following year; but on its own, that's not a reason to ignore the 
agreed cut-off date. Even if we allowed some discretion to land changes 
after the deadline, it would need some justification - perhaps the RFC 
is very small, or amends an existing RFC already in the release.

To me, a well-documented process feels fairer than making subjective 
judgements on the worthiness of every RFC.

I will end, though, by saying I have no particular authority, and this 
is all just my opinion. I wish you well, and look forward to digging 
into your proposal, whichever release it ends up targeting.

Regards,

-- 
Rowan Tommins
[IMSoP]