Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115883
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <alpine.DEB.2.23.453.2108241825130.2773@singlemalt.home.derickrethans.nl>
 <CADK1yXL=HdA5jF9F09vAgvZYzDpxcuN-1vxudwmZ6BXkjtuPKg@mail.gmail.com>
 <C7EF7C8B-A617-4C44-AAD5-B970098EC5AB@php.net> <CADK1yXLuSkMmfBumC4y9g4oP5dP06jgcLeh6S8K57Lum_3i8wQ@mail.gmail.com>
 <48D54138-2930-4935-B979-9A9DE9B403F1@gmail.com>
In-Reply-To: <48D54138-2930-4935-B979-9A9DE9B403F1@gmail.com>
Date: Fri, 27 Aug 2021 18:44:28 +0100
Message-ID: <CA+kxMuT5JEbd9YUAnGx1+Qnv3D4tyiakPkPfbJTc=KRWedunkA@mail.gmail.com>
To: Tobias Nyholm <tobias.nyholm@gmail.com>, Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: Danack@basereality.com (Dan Ackroyd)

Tobias wrote:

> I know you are not a bad person...
>
> The fact that you unprompted (as far as I can tell) decided to in
> detail specify how RMs should make their decision about an RFC is
> giving me a strong signal that you don=E2=80=99t trust the role of the Re=
lease
> Manager. The timing of your RFC is also unfortunate assuming you don=E2=
=80=99t
> want to imply they are doing a poor job as they just got some criticism
> in a different thread.
>
> I may be wrong and the current and previous release managers feel like
> they really need another policy dictating their work, if so I really
> hope you worked with a few of them while you drafted this RFC.

If you're going to call people names, you may as well do it openly,
rather than through passive aggressive phrasing like this.

Also, if you could stop describing decisions that you disagree with as
"obvious mistakes" when the RFC author was pretty clear about the
intention, and the vote passed 30 - 3.

Quite a few times you're giving the impression that you think other
people are dumb if they can't even see this "obvious mistake".

> And to state something I hope is obvious: I am not accusing you for tryin=
g to reduce the role of Release Manager or anything else.

You are projecting here.

You're the person who is proposing giving Release Managers new powers
to have special RFCs where "vote should not consider =E2=80=9Cif it is too
late=E2=80=9D or =E2=80=9Cthis is rushed=E2=80=9D."

> To allow the release managers to have this decision power is not a
> =E2=80=9Cviolation of voter rights=E2=80=9D, that is just a silly argumen=
t.

It's a change from what we've had before, and blowing off other
people's concerns about putting too much power in the hands of a few
people is condescending.

> one way of reading this proposal is that we don=E2=80=99t trust the relea=
se managers to decide what to include and not to include in a release.

To be clear, I don't trust release managers to decide that. Though
they are all lovely people, not all of them have a deep enough
understanding of PHP core to be fully able to evaluate changes.

Coincidentally, it is explicitly listed that the Release Manager role
does not include deciding what gets shipped -
https://wiki.php.net/rfc/releaseprocess#rms_role

"RMs Role - But they are not: Decide which features, extension or SAPI
get in a release or not"

Nicolas Grekas wrote:
> Can you please let me know how that helps?

It helps point out how obtuse you are being.

Yeah, everyone gets it, there are quite a few people who commit to
Symfony who don't like that the "Pure intersection types" RFC only
implemented a pure intersection type and didn't allow a union type
with null.

But having people from that community turn up, call people names, call
things "obvious mistakes" and try to change what feature freeze means
e.g.

> but what is "feature freeze" supposed to mean if we aren't allowed to dis=
cuss,
> alter, or even revert not-yet-released features?!?
> anything that is not yet released should be re-discussable until either
> beta or RC stage.

One of the hardest things to do in an Open Source project is to say
'no' to someone when they are making a request that isn't completely
unreasonable. IMO, it would have been better if the 8.1 RM managers
had said no to opening the "Nullable Intersection types" RFC, but I'm
also pretty sure they expected you to behave better and not to throw
mud around what processes the PHP does or should follow.

If you want people who contribute to PHP core to ship 'more complete'
features, how about getting Symfony the company (or any other company)
to sponsor some of them: https://phpopendocs.com/sponsoring/internals

cheers
Dan
Ack