Hi
On 3/5/24 14:09, Hans Henrik Bergan wrote:
I don't want to spend too much effort on nitpicks, but if someone
volunteers to improve it, I'd be happy to add it, in which case please
send a PR to
https://github.com/divinity76/stuff/blob/phprfc/2024/sleep_function_float_support.md
To set my email in context: For me visuals play an important role in the
overall presentation of an RFC. If it's not properly formatted, it's
harder to read and harder to understand the RFC. Proper formatting also
is some indicator that the author actually cares about the RFC instead
of just throwing stuff over the fence and letting others figure out the
details. This one is simple enough and it's certainly not something that
makes me vote “No” out of spite, but perhaps this is something to keep
in mind for future RFCs.
For (2) it would help if you'd explain what it means for sleep() to be
interrupted and how this can happen. I believe this is signal-handling
related, but writing it out explicitly for the folks that didn't yet
encounter it would probably make sense.
I'm not an expert, but when researching this on Windows 10 + PHP 8.3.2,
[…]
I don't know how to make it return 192 on Windows.. Anyone know?
My remark was not just about Windows (I can't advice here either, I
don't do Windows), adding a short *nix explanation of when sleep will
return earlier than expected would be helpful as well. That's likely the
more common case anyway.
I'd just put a single "Do all of this in the next minor" vote there. All
of the suggested improvements make sense to me and the breaking changes
are mostly theoretical.
meh, I don't want to risk the RFC getting rejected because too many
people thought it should be done in next.major instead of next.minor,
let's keep both next.minor + next.major vote options. (You're probably
right, I predict a majority vote for next.minor for all 3, but i'll
keep the vote options just in case.)
Complicated voting options also risk the RFC getting rejected,
especially if certain combinations of voting options are non-sense (such
as 1: yes, 2: yes, 3: no). Personally I'd rather have no change at all,
instead of a half-baked internally inconsistent change.
Don't forgot to open up a dedicated explicit discussion thread once you move it into the
"Discussion" phase.
How would I even do that? Linking to
https://externals.io/message/122388 isn't sufficient?
Once you are happy with the RFC contents, instead of replying to this
existing thread, send a fresh email to the list, titled "RFC: Support
for Floats in Sleep Function", in there link the RFC and this discussion
thread and say that the discussion period is starting now. This will
ensure it will pop up as a fresh email for the folks who already ignored
the subthread, because they were not interested in the pre-RFC
discussion while stuff is still in flux.
Best regards
Tim Düsterhus
