> > We don't need to solve this now, this week, because there are plenty > of rushed, last-minute proposals on the table already. But I'd like > folks to start thinking about this and ways we can mitigate this > problem come future releases. > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I agree with Sara. This is definitely a worthwhile discussion and the issue probably puts additional stress on RMs that may be easily avoided. Personally (for Class Friendship), I opted to target either 7.4 or 8.0 (whichever was decided to be next-in-line; but *specifically NOT* 7.3 due to more important discussions happening at the moment. So I think there's some "personal judgment calls" to make for folks submitting RFCs. At the same time, I would hate to see a TON of additional process / voting constraints come as a response to this issue. That said, if feature freeze for a release is announced well in advance, published, and there was an agreed "best intentions" policy to not submit RFCs that encroach on that date, then I think all would be well. I don't think there's any intent to slide features in under the finish line. It just seems like a lot of ideas finished baking at a weird time. That, or subconsciously, the talk of a new version of PHP sparked folks to get off their ass and put forth their ideas! :P Just my 2c, FWIW -- Dustin Wheeler | Software Developer NC State University mdwhe...@ncsu.edu "If you don't know where you're going, it's easy to iteratively not get there." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php