Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:122596 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id E2D6A1AD8F6 for ; Sat, 9 Mar 2024 19:46:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1710013590; bh=e4WQ5ewNGmj0bZ95yi1wSYkDQHF/S+cD7F68YIfhq5g=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=GwttR7F4wPH2OXhI6fxLyOVz11j94a27kUHfbvlzT30S4ZNby02hjlnDJhzjlLKc4 htmecUBewtWRXuZs4SnZ/ohcjvJs/N9iawSlD/RNaHzlYKk04MBp3IWMeWYZ/0K5I9 dakGxBmZ6J3vLyYP5ZOglaX1RSo0aMR7MevqR6fhmseSaXXFcXaO9nZLgsrVeYiH93 uACd38UjK+aYxE/nIhNYs0d9xIv03GtR3TPw41C/b8M63FKO2R7fOfE5UFu+wOFIK2 gn7XqmNCuMfvgY+beBZC3Q4E2m+ddN3fAIlIhHAVXZ37EIBnmmJPS8+jF4aXyIXnch N2Z//gLg2zR5w== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E2C621806A6 for ; Sat, 9 Mar 2024 19:46:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from wfout1-smtp.messagingengine.com (wfout1-smtp.messagingengine.com [64.147.123.144]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 9 Mar 2024 19:46:28 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailfout.west.internal (Postfix) with ESMTP id 5B6631C0009D; Sat, 9 Mar 2024 14:46:12 -0500 (EST) Received: from imap47 ([10.202.2.97]) by compute7.internal (MEProxy); Sat, 09 Mar 2024 14:46:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= trainedmonkey.com; h=cc:cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1710013571; x=1710099971; bh=g8aq+4emGBGT0UolTEvFqLPsy7aVaStbKJzyaEDnLXM=; b= a6cTUQKRODgw/8rNF3gJ8fxOVOiROMcCS6orgf74ptuFPIX9XGqA1tUQvtjtGMpU ZaXrX0Sc4UonYQcPDVO+Cuq6/3Mdb0RMu7a+I53tmSVjHY17xKAm5qz5J7TUQrWq UDNJ4BY4RIS7vmAnT1gAv749u+2z23cjRTpbAaAUUbGUV0TM0gH1s3Tky2+DGwnn WiXFv9U6KVLEERKuewKu999QxKKzDP3BGT8uraA6GF07ajkKWWJN5WZOvoUlvU/b wo4xPJ4uIZGHkdJV2IGMQfsQ4pZsSp6scKv9TKcZUU7raA3mUD0DmiCSAvihiJ4D NOzd/LunT5YvqaXvDsQpcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1710013571; x=1710099971; bh=g8aq+4emGBGT0UolTEvFqLPsy7aV aStbKJzyaEDnLXM=; b=loapOS/8iXGdubpCjBtT+RNIetg+JPjO/kMEfpxOL7gD DZTlQ4Dyp9muvV59TMz0Z4QcG0qx08w+f93Rx2QqnX+9sDuNesfCyyLzBbDEsQKh 9G0+D472sLZz75lUFB/N9/0aPspk+qXY124Bbj4rQ37z35ONa+dkakAM8HDIXNEM Btd/sXG7omh5+vDzH7r5OU8x+HrBwl9s3F8dFph/oYoCII0NUTExkyITG5yE6oiv OBxGmNYTPci3AqtWka7ZkNbcarJVLmesZhdKgzei2xlnqzCkWz+Ow54IjIbq/xjR EHuSmrnhSR/15Nw5CWfHbm+kI6uOQzfPGoQMDtcCGg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrieejgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerreejnecuhfhrohhmpedflfhi mhcuhghinhhsthgvrggufdcuoehjihhmfiesthhrrghinhgvughmohhnkhgvhidrtghomh eqnecuggftrfgrthhtvghrnhepjefhveegueetudejkefhkefgveeuueffhedtffetheej teeghfduhfekffejvefgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepjhhimhifsehtrhgrihhnvggumhhonhhkvgihrdgtohhm X-ME-Proxy: Feedback-ID: ia2404087:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 52979A60078; Sat, 9 Mar 2024 14:46:11 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-251-g8332da0bf6-fm-20240305.001-g8332da0b Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 Message-ID: <98641418-c74d-4d2c-8045-f0db95673ae2@app.fastmail.com> In-Reply-To: References: <7d05d51f-f301-4d62-b1c0-83e6a2e0632e@bastelstu.be> Date: Sat, 09 Mar 2024 11:44:29 -0800 To: "Jakub Zelenka" Cc: "Hans Henrik Bergan" , "Larry Garfield" , "php internals" Subject: Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds Content-Type: multipart/alternative; boundary=32b99aaefc274d6fa40a087976cea072 From: jimw@trainedmonkey.com ("Jim Winstead") --32b99aaefc274d6fa40a087976cea072 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 9, 2024, at 5:07 AM, Jakub Zelenka wrote: > On Fri, Mar 8, 2024 at 6:30=E2=80=AFPM Jim Winstead wrote: >> On Fri, Mar 8, 2024, at 12:12 AM, Hans Henrik Bergan wrote: >> > On Tue, 5 Mar 2024 at 20:17, Larry Garfield 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 be= fore), 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? >>=20 >> This is a lot of votes for a set of pretty simple changes with minima= l BC implications, and maybe there's precedent for it but I don't like v= oting about what version to make particular changes in. Adding a languag= e feature like property hooks is a one-vote RFC but fixing sleep() to ta= ke/return floats and work consistently cross-platform is somehow a six-v= ote 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 someh= ow unacceptable? What if #3 fails but not #1? >=20 > I agree that there's a clear dependency on #1 (other way round than th= e 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. Yeah, I got my example a little backwards, but either way is pretty goof= y. >> And I'd say leave it up to the release managers to decide what versio= n it is appropriate for the PR implementing an approved RFC go into. Mic= ro-managing that by voting does not sit well with me. >=20 > RM has no power to decide about features going in before the first bet= a. You would need to update the policies to explicitly give RM such powe= r. Voting is currently the only way we have to decide such thing if ther= e is no clear agreement which I think wasn't the case in the PR's propos= ed for this. This may be a dumb question, but what's the process for determining whet= her the next significant release of PHP will be a minor version or a maj= or version? If the adherence to semantic versioning is meant to be stric= t, it doesn't make any sense to vote on what version something like belo= ngs to, because then you're saying that whether a BC break is significan= t enough to merit an increase to the major version is up for vote. I guess what I'm saying is that one way to deal with it if an RFC is a c= hange that breaks backwards compatibility in any way, it can be passed a= t any time but the change only lands in whatever the next major version = may be. So the RFC could have passed for this change to sleep() back bef= ore 8.1 was ever released and the change would just be waiting for the n= ext release of a major version, subject to whatever process there is for= deciding whether the next significant release is a major or minor versi= on. (The way I think I would prefer is trusting the release managers to judg= e whether a BC break is significant enough to merit putting a change on = ice until the next major version. Doing it by vote feels like excessive = micro-management by voting, and doing it three times in one RFC for the = sleep() function is bonkers.) Jim --32b99aaefc274d6fa40a087976cea072 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 9, 2024, at 5:07 AM, Jakub Zelenka wrote:
<= /div>
On Fri, Mar 8, 2024 at 6:30=E2=80=AFPM Jim Winstead <jimw@trainedmonkey.com> w= rote:
On Fri, Mar 8, 2024, a= t 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 se= nse.  What happens if none of the 3 options reaches 66%?
<= div> >>
>> The viable options here are a sing= le RCV vote (which we've done before), or a single "Should we do this" v= ote that requires 66%, followed by a "when should we do this" vote with = 2 options, majority wins.
>>
>>= ; --Larry Garfield
>
> Does this wor= k for you guys?

This is a lot of votes fo= r 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 feature like property hook= s is a one-vote RFC but fixing sleep() to take/return floats and work co= nsistently cross-platform is somehow a six-vote ballot? Is there anyone = who has indicated in any way that they would vote against making all thr= ee 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 actual= ly... :) ). 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 vote= s in this case as each thing has its own consideration and BC impact whi= ch is primary difference compare to hooks RFC.

Yeah, I got my example a little backwards, but either way= is pretty goofy.

<= blockquote type=3D"cite" id=3D"qt" style=3D"">
And I'd say leave it up to the release manager= s to decide what version it is appropriate for the PR implementing an ap= proved 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 whi= ch I think wasn't the case in the PR's proposed for this.

This may be a dumb question, but what's the pr= ocess for determining whether the next significant release of PHP will b= e a minor version or a major version? If the adherence to semantic versi= oning is meant to be strict, it doesn't make any sense to vote on what v= ersion something like belongs to, because then you're saying that whethe= r a BC break is significant enough to merit an increase to the major ver= sion is up for vote.

I guess what I'm saying is that one = way to deal with it if an RFC is a change that breaks backwards compatib= ility in any way, it can be passed at any time but the change only lands= in whatever the next major version may be. So the RFC could have passed= for this change to sleep() back before 8.1 was ever released and the ch= ange would just be waiting for the next release of a major version, subj= ect to whatever process there is for deciding whether the next significa= nt release is a major or minor version.

(The way I think = I would prefer is trusting the release managers to judge whether a BC br= eak is significant enough to merit putting a change on ice until the nex= t major version. Doing it by vote feels like excessive micro-management = by voting, and doing it three times in one RFC for the sleep() function = is bonkers.)

Jim
--32b99aaefc274d6fa40a087976cea072--