On not rushing things at the last minute

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

On 7/10/2018 6:10 AM, Sara Golemon wrote:

I'd like to see confirmed security vulnerabilities and bug squashing be made a priority over new features. Bug #73535 is still open, unaddressed, and unmitigated...

Hi, On Tue, Jul 10, 2018 at 4:10 PM, Sara Golemon <pollita@php.net> wrote:

Aside from life keeping you busy until you realize it's that time of the year again, I believe it's just the short development cycle and is no coincidence that this has been happenning more often since getting into a yearly schedule. In my observation, adoption rates are slower than the release cycle and so it's kind of like ... I barely got to enjoy the shiny new thing and the next feature freeze is already happening. And then also, we're always eager to get our idea in before feature freeze, but that's hard to achieve unless we come up with it in January or earlier, but since everybody's naturally got their eyes set on version.next, few people think about X.Z before X.Y is released. I don't know if this can be fixed though. It's just hard to keep up with schedules on side projects and let's face it - PHP is nobody's primary job, so any work spent on it is by definition a side project. Cheers, Andrey.

Hi!

Yeah, I think it is natural (when deadline is closing in, people start to rush in), but not good. And I would feel for big features, like typed properties or friend classes (without touching its merits) I think they should target 7.4. In the future, I think the expectation should be that if you have a large improvement it should not be expected to land in the version that is already in the release cycle, even before feature freeze (especially if "before" is measured in mere days). Large features take time to figure out and stabilize, and that should be the expectation. So you can write the RFC and open the vote whenever you want and whenever the life allows you the time to do it, but the expectation of where it lands should not be "immediately", especially for big ones. What is "big" is subjective of course, but deep language level changes (typing, strictness, changing how major parts of language work, major language feature like, I dunno, named arguments?) are big, and most deprecations or individual function additions aren't.

On 10/07/2018 14:10, Sara Golemon wrote:

I have noticed three approximate (and overlapping) categories of late RFC: 1) Submarine features: Features which have been developed over a long period, but where the author wanted to get things polished before formally announcing, e.g. typed properties 2) Quicky features: Simple changes which people have been *mentally* working on, often just deprecations and edge-case handling changes 3) Sleeping RFCs: Changes which enter initial discussion, go quiet, and sit in "Under Discussion" without reaching a vote In all three cases, I think the general psychology of deadlines comes into play: it's easy to put off those finishing touches when you've got plenty of time, then jump into action at the last minute. There seems to also be a reluctance to target anything other than the current cycle; partly just because "would you like it released in 6 months or 18 months?" is usually "sooner!" One thing that might help, particularly with the 1st and 3rd categories there, is a clearer set of statuses for RFCs and other features. We currently have 61 RFCs in the "Under Discussion" section of https://wiki.php.net/rfc; some of these are effectively abandoned, others just need polishing and taking to a vote. Then there are any number of experiments and TODO lists which could turn into a "submarine" or "quicky" feature. I'm not sure of the exact formula, but some possible lines of thought... - Have a separate status, or a separate list (dare I call it a "roadmap"?) for the RFCs targeting each release? - Include items on that list that aren't ready for an RFC yet? - Find some way to prune that list at key points in the release cycle? - Have some kind of inactivity timeout for what counts as "Under Discussion"? Maybe a new status/heading of "Dormant"? - Have a "put up or shut up" deadline? e.g. if you announce a feature targeting 7.4 now, you have to put it to vote by, say, March, not keep it ticking over until next July Regards,