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

Reply via email to