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]