Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122592
Precedence: bulk
MIME-Version: 1.0
References: <CAK7R4azyh4Yi6NjYFLwD_9BMeH9TD8YmTxQ46cn96Z7cCVy-eA@mail.gmail.com>
 <A813DBD2-219F-404C-AB67-AD5ECA0124C2@gmail.com> <CAJmy8YHOCkvEec1WQbjzAomRwmU3H3+wqfoz4UVXcMmE-kb8uw@mail.gmail.com>
 <7d05d51f-f301-4d62-b1c0-83e6a2e0632e@bastelstu.be> <CAJmy8YHMFv3jriQeic1rBm17DFqzsLSAkYeB_kWmw87XYJd3_Q@mail.gmail.com>
 <b14fa7e8-5d6b-4125-8ff1-95fef05142b9@app.fastmail.com> <CAJmy8YEfpymBkdJto_yKZKMM7dr+H_SrbdEz08dfrqVi254NBA@mail.gmail.com>
 <ff3ab4b4-6c7a-4013-b5a1-06d42d9b93c0@app.fastmail.com>
In-Reply-To: <ff3ab4b4-6c7a-4013-b5a1-06d42d9b93c0@app.fastmail.com>
Date: Sat, 9 Mar 2024 13:07:17 +0000
Message-ID: <CAEKnhAEr6+SymUf+yqmc2ERZPmLHJGFkr+LO6pYdgpATgN6ybQ@mail.gmail.com>
Subject: Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds
To: Jim Winstead <jimw@trainedmonkey.com>
Cc: Hans Henrik Bergan <divinity76@gmail.com>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005ae649061339feb7"
From: bukka@php.net (Jakub Zelenka)

--0000000000005ae649061339feb7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 8, 2024 at 6:30=E2=80=AFPM Jim Winstead <jimw@trainedmonkey.com=
> wrote:

> On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote:
> > On Tue, 5 Mar 2024 at 20:17, Larry Garfield <larry@garfieldtech.com>
> wrote:
> >>
> >> A 3 way up-down vote doesn't make sense.  What happens if none of the =
3
> options reaches 66%?
> >>
> >> The viable options here are a single RCV vote (which we've done
> before), or a single "Should we do this" vote that requires 66%, followed
> by a "when should we do this" vote with 2 options, majority wins.
> >>
> >> --Larry Garfield
> >
> > Does this work for you guys?
>
> This is a lot of votes for a set of pretty simple changes with minimal BC
> implications, and maybe there's precedent for it but I don't like voting
> about what version to make particular changes in. Adding a language featu=
re
> like property hooks is a one-vote RFC but fixing sleep() to take/return
> floats and work consistently cross-platform is somehow a six-vote ballot?
> Is there anyone who has indicated in any way that they would vote against
> making all three changes because one of the three is somehow unacceptable=
?
> What if #3 fails but not #1?
>
>
I agree that there's a clear dependency on #1 (other way round than the
above actually... :) ). It might make more sense to do #1 as a primary vote
and then the rest as a secondary votes. I think it makes sense to have more
votes in this case as each thing has its own consideration and BC impact
which is primary difference compare to hooks RFC.


> And I'd say leave it up to the release managers to decide what version it
> is appropriate for the PR implementing an approved RFC go into.
> Micro-managing that by voting does not sit well with me.
>
>
RM has no power to decide about features going in before the first beta.
You would need to update the policies to explicitly give RM such power.
Voting is currently the only way we have to decide such thing if there is
no clear agreement which I think wasn't the case in the PR's proposed for
this.

Regards

Jakub

--0000000000005ae649061339feb7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Mar 8, 2024 at 6:30=E2=80=AFPM Ji=
m Winstead &lt;<a href=3D"mailto:jimw@trainedmonkey.com">jimw@trainedmonkey=
.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Fri, Mar 8, 2024, at 12:12 AM, Hans Hen=
rik Bergan wrote:<br>
&gt; On Tue, 5 Mar 2024 at 20:17, Larry Garfield &lt;<a href=3D"mailto:larr=
y@garfieldtech.com" target=3D"_blank">larry@garfieldtech.com</a>&gt; wrote:=
<br>
&gt;&gt;<br>
&gt;&gt; A 3 way up-down vote doesn&#39;t make sense.=C2=A0 What happens if=
 none of the 3 options reaches 66%?<br>
&gt;&gt;<br>
&gt;&gt; The viable options here are a single RCV vote (which we&#39;ve don=
e before), or a single &quot;Should we do this&quot; vote that requires 66%=
, followed by a &quot;when should we do this&quot; vote with 2 options, maj=
ority wins.<br>
&gt;&gt;<br>
&gt;&gt; --Larry Garfield<br>
&gt;<br>
&gt; Does this work for you guys?<br>
<br>
This is a lot of votes for a set of pretty simple changes with minimal BC i=
mplications, and maybe there&#39;s precedent for it but I don&#39;t like vo=
ting about what version to make particular changes in. Adding a language fe=
ature like property hooks is a one-vote RFC but fixing sleep() to take/retu=
rn floats and work consistently cross-platform is somehow a six-vote ballot=
? Is there anyone who has indicated in any way that they would vote against=
 making all three changes because one of the three is somehow unacceptable?=
 What if #3 fails but not #1?<br>
<br></blockquote><div><br></div><div>I agree that there&#39;s a clear depen=
dency on #1 (other way round than the above actually... :) ). It might make=
 more sense to do #1 as a primary vote and then the rest as a secondary vot=
es. I think it makes sense to have more votes in this case as each thing ha=
s its own consideration and BC impact which is primary difference compare t=
o hooks RFC.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
And I&#39;d say leave it up to the release managers to decide what version =
it is appropriate for the PR implementing an approved RFC go into. Micro-ma=
naging that by voting does not sit well with me.<br><br></blockquote><div><=
br></div><div>RM has no power to decide about features going in before the =
first beta. You would need to update the policies to explicitly give RM suc=
h power. Voting is currently the only way we have to decide such thing if t=
here is no clear agreement which I think wasn&#39;t the case in the PR&#39;=
s proposed for this.</div><div><br></div><div>Regards</div><div><br></div><=
div>Jakub=C2=A0</div></div></div>

--0000000000005ae649061339feb7--