Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120171
MIME-Version: 1.0
References: <CAEKnhAEfQqNuk9Ah7OeyA756r5P1Z=iaqqEXAgr1kxTAbbvLmQ@mail.gmail.com>
In-Reply-To: <CAEKnhAEfQqNuk9Ah7OeyA756r5P1Z=iaqqEXAgr1kxTAbbvLmQ@mail.gmail.com>
Date: Mon, 1 May 2023 18:00:06 +0100
Message-ID: <CA+kxMuRnvkT7H-aWbKZKCOzDyh=CsBzLLXW+1gadneMZh=QUQA@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Current RFC process and project decisions
From: Danack@basereality.com (Dan Ackroyd)

On Mon, 1 May 2023 at 12:21, Jakub Zelenka <bukka@php.net> wrote:

> It seems that in the current definition, the RFC is just for blocking
> rejected features to get to the next release rather than requiring accepted
> features to be in the next release....It means it requires some
> sort of consensus between core developers or at least no objections from
> some core developers.

It might be better to think of the RFC process for new features to be
a decision on "should this feature be in PHP?" rather than a "must
this feature be in PHP?".

As far as I can remember, there is a single RFC that wasn't merged in
the next planned release:
https://wiki.php.net/rfc/null_coalesce_equal_operator

The vote was passed on 2016/04/02 so 7.1 was the next release version,
but it wasn't merged until 2019/01/22 and so was in PHP 7.4.

That was due to a technical problem with the implementation - I don't
recall/understand the exact details. But it wasn't (afaik) a
controversial decision to not merge it until the patch was good
enough.

This was possible to happen because we don't require a complete patch
that is ready to merge. Ironing out all of the minor details for a new
feature is a huge amount of work (that people in userland are usually
completely oblivious to) which would increase the burden of passing
RFCs.

Seeing as one of the big long term problems PHP has, is that many
contributors stop contributing after they get burnt out by doing an
RFC, I would oppose making RFCs take more work.

Once an RFC is passed the conversation changes from whether the RFC is
a good idea or not, to being a conversation about how to best
implement it, and whether the patch has some show-stopper issues or
not.

> This is largely undefined as almost always the core
> developers would follow the decision in RFC but technically there is
> nothing in our process that would require them to do so.

Technically correct. Though the situation where all of the core
contributors refuse to merge a PR, probably means the PR shouldn't be
merged.

> The idea is to maybe create a single document in the wiki collecting both
> linked RFCs with extended clarifications and maybe mirror it in git so the
> future proposal are easier to do.

At the risk of being a senior programmer; what problem are you trying to solve?

I mean, clearly there have been problems that could do with clarifying:

* when are and what types of code cleanups allowed to happen? What
notice should be given, to avoid causing work for other developers,
who might have large existant branches they've been working on?

* are pull-requests that merely add comments allowed? This is
something some long-time core contributors have strong feelings about,
which I and other people disagree strongly with, but we haven't had a
framework to discuss it without shouting.

And there are probably other non-userland affecting code maintenance tasks.

But as far as as I'm aware, there hasn't been a problem with an RFC
passing and the core contributors refusing to accept it. So please can
we discuss the exact problem you want to solve, so that we can agree
it's the right problem to solve, before suggesting solutions?

If nothing else, some problems are unsolvable by lots of documentation
and bye-laws.

cheers
Dan
Ack