On Mon, Jul 28, 2025 at 7:17 PM Gina P. Banyard <intern...@gpb.moe> wrote:
> On Monday, 28 July 2025 at 16:22, Tim Düsterhus <t...@bastelstu.be> wrote: > > > Am 2025-07-28 16:23, schrieb Gina P. Banyard: > > > > > As I am aware it is in bad taste to shove something new into such a > > > proposal minutes before starting the vote, > > > I'll postpone the vote for a few hours so that at least some people > > > can see and raise objections. > > > > > > For visibility: I object. See sibling email. > > Said sibling email: > > On Monday, 28 July 2025 at 15:31, Tim Düsterhus <t...@bastelstu.be> wrote: > > Am 2025-07-28 16:20, schrieb Gina P. Banyard: > > > > > I've added a whole new section that addresses this, as out of range > > > casts are completely whack. > > > See: > > > > https://wiki.php.net/rfc/warnings-php-8-5#casting_out_of_range_floats_to_int > > > > > > This effectively is another “Primary Vote” for an entirely new proposal > > and as such requires 2 weeks of discussion. If you want to vote on this > > RFC for PHP 8.5, you'll need to drop that section again. > > > > Best regards > > Tim Düsterhus > > I am going to bring the RFC in its totality to a vote later today. > You can consider this a new primary vote, vote no, and even argue for this > part of the RFC to be rendered void regardless of the result. > Or just incentivize people to vote no, so you don't even need to deal with > this. > > Claude raised the edge case 2 days ago, and I found the extent of it to be > even larger than expected. > I thought that it would be better to create a whole new section rather > than twisting the existing "NAN" warning proposal to fit the new > constraints, > but apparently I should have done this instead and changed all instances > of "NAN" to "non-representable floats". > > I find it increasingly frustrating that trying to make PHP not be > completely insane is met with resistance at every turn, > and I'm once more at the stage that I really should stop wasting my time > and caring about PHP and do something better with my life. > Using "process violations" to prevent PHP from being less shit when an > additional edge case of a proposal is found, for IDK 5 additional years > impacting countless developers, old and new, is something that I find > infuriating. > And I guess this truly showcases how broken and infuriating our RFC > process can be, especially around feature freeze. > > Moreover, if we are going to do legalese, the only thing our policy actual > states are the following: [1] > > > There'd be a minimum of 2 weeks between when an RFC that touches the > language is brought up on this list and when it's voted on is required. > [...] > > > For procedural reasons, multiple RFCs may be combined into one, in which > case there may be multiple primary votes. > > Combining multiple RFCs into one does not allow turning a primary vote > into a secondary vote. > > There is no mention of the content of an RFC needing to be "identical" for > 2 weeks. > I guess this is a bit of a loop hole in the process but essentially I think you have got right to add such last minute changes to the RFC and open vote next day (or even next minute) if you want. The current policy doesn't really consider those multi vote RFC's but technically it's still a single RFC which is announced on internal just once and the date of announcement on internals is what matters. If we should change those rules is really for another discussion though. Jakub
