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

[email protected] ("Rowan Tommins [IMSoP]") Thu, 23 Jul 2026 12:23:27 +0100
Newsgroups php.internals
Message-ID <[email protected]>
Hi Pierre,

I should probably make this my last reply in this thread and see if others=
 have anything to add, but I wanted to pick up on one point:

On 23 July 2026 04:35:36 BST, Pierre Joye <pierre=2Ephp@gmail=2Ecom> wrote=
:
>It makes it as nothing is being actually reviewed but rejected
>straight down due to policies=2E Hence my bureaucracy statement=2E

I think if this was a small RFC, and people were refusing to read it becau=
se of a technicality, that criticism would be justified=2E

But I'm not sure it's entirely fair in this case=2E There are maybe twenty=
 sections describing details of the proposal, and the crude "reading time" =
estimate in Firefox is 47-60 minutes=2E It may be clear in your head that m=
ost of this is uncontroversial, but for anyone else to even make that judge=
ment requires investing a reasonable amount of time=2E

For many people, spending that time means spending less time on a differen=
t discussion=2E So it's not necessarily about bureaucracy, but a pragmatic =
decision: it's better to spend time now discussing proposals which are defi=
nitely targeting 8=2E6, and spend time later on proposals which will end up=
 in 8=2E7=2E

That trade-off changes if we need to spend time deciding on the target ver=
sion based on the content of each proposal, which is why I support the idea=
 of a simple rule that everyone agrees in advance=2E

I do think there's an entirely separate question of *when* that hard cut-o=
ff should be=2E Should RFCs be allowed all the way through the alpha period=
? Should the alpha period be shorter, or later in some way? I've never been=
 involved enough in the process to answer those questions=2E=20

Regards,

Rowan Tommins
[IMSoP]