Updates needed to various RFCs

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

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

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

Kind regards,
Jorg

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