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:
Is the RFC (still) in the correct section on the RFC overview page [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:
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.
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
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.
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.
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
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.
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: Smile, Juliette
···
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/adding_bcround_bcfloor_bcceil_to_bcmath)
- [https://wiki.php.net/rfc/grapheme_str_split](https://wiki.php.net/rfc/grapheme_str_split)
- [https://wiki.php.net/rfc/unbundle_imap_pspell_oci8](https://wiki.php.net/rfc/unbundle_imap_pspell_oci8)
- [https://wiki.php.net/rfc/raising_zero_to_power_of_negative_number](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 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!)
Good to know. Thanks for clarifying. 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
···
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).
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.
