Everything

php

Home » Project » Newsgroups » php.internals » Updates needed to various RFCs »

Updates needed to various RFCs

php.internals

Unnamed Person

2 years ago

L.S.,

I'm currently going through the RFC wiki page and I'm seeing various
(PHP 8.4) RFCs which haven't been properly updated after the vote.

I'm specifically referring to the updates which are expected to be made
to an RFC as listed in point 7 and 8 in the "RFC How to" [1].

Typical examples:
- Missing "Target Version" meta data
- Missing implementation (commit/PR) link in the meta data (when merged)
- Missing PR link(s) in the "Implementation" section at the bottom of
the RFC

There are also a number of RFCs where their status in relation to PHP
8.4 is unclear (accepted, but still under "Pending implementation" - and
no, I'm not talking about the recently accepted RFCs, but about RFCs
like `bcdivmod()`).

I'd like to kindly request RFC initiators/owners to have a critical look
at their RFCs with regards to:
1. Is the RFC (still) in the correct section on the RFC overview page [2] ?
2. Has the RFC been updated with relevant implementation links and such ?

Please update when necessary.

I've not gone through all of the RFCs, but these are definitely some
which I'd like to flag for attention:
- https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
- https://wiki.php.net/rfc/grapheme_str_split
- https://wiki.php.net/rfc/unbundle_imap_pspell_oci8
- https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number

Thanks!

Smile,
Juliette


1: https://wiki.php.net/rfc/howto
2: https://wiki.php.net/rfc

Christoph Becker

2 years ago

On 11.08.2024 at 08:05, Juliette Reinders Folmer wrote:

> I'm currently going through the RFC wiki page and I'm seeing various
> (PHP 8.4) RFCs which haven't been properly updated after the vote.
>
> I've not gone through all of the RFCs, but these are definitely some
> which I'd like to flag for attention:
> - https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
> - https://wiki.php.net/rfc/grapheme_str_split
> - https://wiki.php.net/rfc/unbundle_imap_pspell_oci8
> - https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number

Thanks for reporting!

I've fixed up the first two, but I haven't yet found the PRs regarding
the extension unbundling, and I'm unsure about the implementation of the
last RFC; the implementation section has PR #13128, but mentions
"without fpow yet".

On a general note, the whole administrative part of the RFC process
feels like we're stuck in the 20th century.  For instance, to start the
vote, you are supposed to:

* update the RFC page to "voting" status
* add the doodle voting macro
* add the voting start and end dates to the text of the RFC
* move the RFC to "voting" on the RFC overview page
* send an email to the ML announcing the start of voting

Wut?  Might as well ask me to send a punched card to someone.

Cheers,
Christoph

Ayesh - PHP.Watch

2 years ago

> I've fixed up the first two, but I haven't yet found the PRs regarding
> the extension unbundling [snip]
>

I'm watching the php-src repo for some writing stuff and noted down the
commits; here are the ones related to the `unbundle_imap_pspell_oci8` RFC.
Hope it helps :)

- Remove `pdo_oci` and `oci8`:
https://github.com/php/php-src/commit/a4d64b2605f18d9d015fa3e69b7da87847e27662
- Remove IMAP: https://github.com/php/php-src/pull/13190
- Remove
https://github.com/php/php-src/commit/b035cb6c8e31bea351f169b3e9f34fdc562e77e1

Christoph Becker

2 years ago

On 11.08.2024 at 19:06, Ayesh Karunaratne wrote:

>> I've fixed up the first two, but I haven't yet found the PRs regarding
>> the extension unbundling [snip]
>
> I'm watching the php-src repo for some writing stuff and noted down the
> commits; here are the ones related to the `unbundle_imap_pspell_oci8` RFC.
> Hope it helps :)
>
>  - Remove `pdo_oci` and `oci8`:
> https://github.com/php/php-src/commit/a4d64b2605f18d9d015fa3e69b7da87847e27662
>  - Remove IMAP: https://github.com/php/php-src/pull/13190
>  - Remove
> https://github.com/php/php-src/commit/b035cb6c8e31bea351f169b3e9f34fdc562e77e1

Thank you, that was indeed helpful!

Christoph

Deleu

2 years ago

> On 11 Aug 2024, at 13:59, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>
> On a general note, the whole administrative part of the RFC process
> feels like we're stuck in the 20th century.  For instance, to start the
> vote, you are supposed to:
>
> * update the RFC page to "voting" status
> * add the doodle voting macro
> * add the voting start and end dates to the text of the RFC
> * move the RFC to "voting" on the RFC overview page
> * send an email to the ML announcing the start of voting
>
> Wut?  Might as well ask me to send a punched card to someone.
>
> Cheers,
> Christoph

I'd be willing to bet that PHP community members would gladly reimplement the RFC system, voting, etc. and gift that to the PHP Group. However, whenever these conversations popup on internals, it is received with resistance to change and with unsound requirements such as "we can't use any PHP framework to not seem like we favour one group over the other". What's left behind is exactly what you described here: outdated process and implementation. The PHP community spent a large chunk of work in the late 2010s just to phase out corporate homemade frameworks for the usual maintenance reasons.

Jim Winstead

2 years ago

On Aug 11, 2024, at 10:22 AM, Marco Aurélio Deleu <deleugyn@gmail.com> wrote:

> On 11 Aug 2024, at 13:59, Christoph M. Becker <cmbecker69@gmx.de> wrote:
>>
>> On a general note, the whole administrative part of the RFC process
>> feels like we're stuck in the 20th century.  For instance, to start the
>> vote, you are supposed to:
>>
>> * update the RFC page to "voting" status
>> * add the doodle voting macro
>> * add the voting start and end dates to the text of the RFC
>> * move the RFC to "voting" on the RFC overview page
>> * send an email to the ML announcing the start of voting
>>
>> Wut?  Might as well ask me to send a punched card to someone.
>>
>
> I'd be willing to bet that PHP community members would gladly reimplement the RFC system, voting, etc. and gift that to the PHP Group. However, whenever these conversations popup on internals, it is received with resistance to change and with unsound requirements such as "we can't use any PHP framework to not seem like we favour one group over the other". What's left behind is exactly what you described here: outdated process and implementation. The PHP community spent a large chunk of work in the late 2010s just to phase out corporate homemade frameworks for the usual maintenance reasons.

Work is underway, slowly because there are not many people involved and we are trying to be careful, to document and clean up some of the underlying project infrastructure. To get involved, I’d invite anyone to join the php-webmaster@lists.php.net list. Essential skills required right now: patience and a willingness to ask questions.

Jim

Bilge

2 years ago

On 11/08/2024 17:55, Christoph M. Becker wrote:

> On a general note, the whole administrative part of the RFC process
> feels like we're stuck in the 20th century.  For instance, to start the
> vote, you are supposed to:
>
> * update the RFC page to "voting" status
> * add the doodle voting macro
> * add the voting start and end dates to the text of the RFC
> * move the RFC to "voting" on the RFC overview page
> * send an email to the ML announcing the start of voting
>
> Wut?  Might as well ask me to send a punched card to someone.

Well yes, but, you'd need programmers to automate something like that.
And I don't know anyone like that.

Unnamed Person

2 years ago

On 11-8-2024 18:55, Christoph M. Becker wrote:

> On 11.08.2024 at 08:05, Juliette Reinders Folmer wrote:
>
>> I'm currently going through the RFC wiki page and I'm seeing various
>> (PHP 8.4) RFCs which haven't been properly updated after the vote.
>>
>> I've not gone through all of the RFCs, but these are definitely some
>> which I'd like to flag for attention:
>> - https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath
>> - https://wiki.php.net/rfc/grapheme_str_split
>> - https://wiki.php.net/rfc/unbundle_imap_pspell_oci8
>> - https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number
> Thanks for reporting!
>
> I've fixed up the first two, but I haven't yet found the PRs regarding
> the extension unbundling, and I'm unsure about the implementation of the
> last RFC; the implementation section has PR #13128, but mentions
> "without fpow yet".

Thanks Christoph! I was tempted to update the RFCs myself, but thought
it was against protocol for anyone but the RFC owner to do so ? hence my
email.

If you need links to PRs/commits, I've got them, as I've been looking
them up for the initial PHPCompatibility package updates.

For fpow(), these are the relevant ones (and include the fpow() function
in contrast to the text in the PR description - PR was updated after it
was originally pulled):
PR: php/php-src#13128
Commit:
https://github.com/php/php-src/commit/23afe57f01e0915eef246eba60e60fda74fd2dcf

Smile,
Juliette

Joerg Sowa

2 years ago

Thank you, Juliette. I added missing information to my RFC: Raising zero to
the power of negative number.

Kind regards,
Jorg

Christoph Becker

2 years ago

On 11.08.2024 at 22:21, Juliette Reinders Folmer wrote:

> Thanks Christoph! I was tempted to update the RFCs myself, but thought
> it was against protocol for anyone but the RFC owner to do so ? hence my
> email.

Changing an open RFC without consent of the RFC author(s) is certainly
against protocol.  However, in my opinion it is perfectly fine to update
such "meta" information for closed RFCs (i.e. RFCs which have been
implemented or declined or withdrawn).  Especially implemented RFCs
which are linked from UPGRADING *should* be updated in this regard as
soon as possible to avoid readers being confused where to find the
implementation (and such readers might be those who want to write
documentation, and sometimes need to look up the implementation or its
discussion).  And it's equally important to update declined RFCs;
understandably, authors of such RFCs might not want to spend more time
on the gory details of the RFC process. :)

>  If you need links to PRs/commits, I've got them, as I've been looking
> them up for the initial PHPCompatibility package updates.

Please feel free to update the necessary information yourself.  Unless
you tick the "minor changes" checkbox (what you probably shouldn't do
for such updates, unless when moving RFCs on the overview page to the
correct sections), a notification is available as public RSS feed, so
everyone can follow this, and going back to an older version of the RFC
would be a matter of a couple of clicks.  And frankly, I don't think an
RFC author would have an issue if somebody else catches up on what they
just might have forgotten.

> For fpow(), these are the relevant ones (and include the fpow() function
> in contrast to the text in the PR description - PR was updated after it
> was originally pulled):

Jorg has updated the RFC in the meantime (thanks!)

Christoph

Unnamed Person

2 years ago

Christoph,

On 12-8-2024 0:18, Christoph M. Becker wrote:

> On 11.08.2024 at 22:21, Juliette Reinders Folmer wrote:
>
>> Thanks Christoph! I was tempted to update the RFCs myself, but thought
>> it was against protocol for anyone but the RFC owner to do so ? hence my
>> email.
> Changing an open RFC without consent of the RFC author(s) is certainly
> against protocol.  However, in my opinion it is perfectly fine to update
> such "meta" information for closed RFCs (i.e. RFCs which have been
> implemented or declined or withdrawn).

Good to know. Thanks for clarifying.

>
>>   If you need links to PRs/commits, I've got them, as I've been looking
>> them up for the initial PHPCompatibility package updates.
> Please feel free to update the necessary information yourself.  Unless
> you tick the "minor changes" checkbox (what you probably shouldn't do
> for such updates, unless when moving RFCs on the overview page to the
> correct sections), a notification is available as public RSS feed, so
> everyone can follow this, and going back to an older version of the RFC
> would be a matter of a couple of clicks.  And frankly, I don't think an
> RFC author would have an issue if somebody else catches up on what they
> just might have forgotten.

I'll keep that in mind for the future (gone through most RFCs now before
I saw this reply).
Also good to know about not ticking the "minor changes" checkbox.

Thanks, Juliette