Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120172
MIME-Version: 1.0
References: <CAEKnhAEfQqNuk9Ah7OeyA756r5P1Z=iaqqEXAgr1kxTAbbvLmQ@mail.gmail.com>
 <CA+kxMuRnvkT7H-aWbKZKCOzDyh=CsBzLLXW+1gadneMZh=QUQA@mail.gmail.com>
In-Reply-To: <CA+kxMuRnvkT7H-aWbKZKCOzDyh=CsBzLLXW+1gadneMZh=QUQA@mail.gmail.com>
Date: Mon, 1 May 2023 19:39:26 +0100
Message-ID: <CAEKnhAGu4z0NmPgj_rGSVFA+1mdHsCqD=v8vsgaky1NXA-E_og@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000224ce305faa6258e"
Subject: Re: [PHP-DEV] Current RFC process and project decisions
From: bukka@php.net (Jakub Zelenka)

--000000000000224ce305faa6258e
Content-Type: text/plain; charset="UTF-8"

Hi,

On Mon, 1 May 2023, 18:00 Dan Ackroyd, <Danack@basereality.com> wrote:

> 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?".
>

Yes this exactly what I was trying say. One of the reasons for this thread
was actually to prevent misconception that accepted RFC is a final decision
which I have feeling some voters might think.

This is essentially mainly meant for technical changes where such RFC
decision does not make any sense IMHO. Basically we decide about anything
technical in RFC that explicitly allows leaving decision of merging for
later.


> 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.
>

Just to clarify I don't have any problem with that. Personally I think the
RFC process works fine for user facing changes and proposing changes with
minimal implementation is fine in my eyes.


> 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.
>

I agree and I would personally prefer not to do RFC for changes that are
not controversial. Certainly I wouldn't want to make it worse.


> 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?
>

The proposed single document is not meant to solve problems but improve
things and make the rules clear and easy to find for new contributors. It
should also remove all conflicting statements and it should also make the
modification easier.


> 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?
>

Yes this is exactly something that should not be addresed by the RFC IMO

>
> * 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.
>

This is in some way the same as the above. Basically for me the main issue
is that the RFC is the only place where conflicting technical issues
between developers are decided.

I think having such framework is really something that would be great to
have. The TC proposal is such an attempt actually.


> 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?
>

As I said it was mainly about improvements and making things clear at this
stage which should allow further changes in the future. In terms of those
chnges that I would like to see is to mainly having some framework for
dealing with technical changes.

Cheers

Jakub

>

--000000000000224ce305faa6258e--