Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115884
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
In-Reply-To: <CA+kxMuT5JEbd9YUAnGx1+Qnv3D4tyiakPkPfbJTc=KRWedunkA@mail.gmail.com>
Date: Fri, 27 Aug 2021 11:11:02 -0700
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <828C15A4-86D3-43EE-960F-05B4EA7DEB23@gmail.com>
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>
 <CA+kxMuT5JEbd9YUAnGx1+Qnv3D4tyiakPkPfbJTc=KRWedunkA@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: tobias.nyholm@gmail.com (Tobias Nyholm)

Hey Dan.

I see that you read what I wrote and intrepid it in the worst possible =
way. I will try to be more clear and more carefully chose my words in =
the future.=20

I called it an =E2=80=9Cobvious mistake=E2=80=9D because it was clear to =
me that we missed something. We are not bad people or worse developers =
because we made a mistake. We (the community) are also not shielded from =
making mistakes just because we have a voting process. I understand that =
other people are not consider it to be a mistake. That is fine. I am =
wrong to call it =E2=80=9Cobvious=E2=80=9D.=20

>> one way of reading this proposal is that we don=E2=80=99t trust the =
release managers to decide what to include and not to include in a =
release.
>=20
> 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.

I think there are over 1000 people with =E2=80=9Cvoting powers=E2=80=9D. =
I assume you trust a majority of them to have this =E2=80=9Cdeep enough =
understanding of PHP core=E2=80=9D.

If you don=E2=80=99t trust the release managers to manage the release, =
then I suggest you should improve the way we select new release =
managers.=20


> 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,

Yes, but it does not mean that you *have to* say no.
But I do agree with you. The process would have been way better if they =
said =E2=80=9Cno". Or if they clearly and unanimously said =E2=80=9Cyes=E2=
=80=9D which would remove focus on =E2=80=9Cit feels rushed=E2=80=9D and =
=E2=80=9Cwe can=E2=80=99t because of feature freeze=E2=80=9D.
This is the the extended power I would like the RMs (as a group) to =
have.=20

To be clear, Im not suggesting they should veto every RFC. Just changes =
during feature freeze. Since RMs are experienced open source developers, =
Im sure they know to ask for help privately whenever they need it.=20

// Tobias


> On 27 Aug 2021, at 10:44, Dan Ackroyd <Danack@basereality.com> wrote:
>=20
> Tobias wrote:
>=20
>> I know you are not a bad person...
>>=20
>> 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 Release
>> 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.
>>=20
>> 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.
>=20
> If you're going to call people names, you may as well do it openly,
> rather than through passive aggressive phrasing like this.
>=20
> 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.
>=20
> 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".
>=20
>> And to state something I hope is obvious: I am not accusing you for =
trying to reduce the role of Release Manager or anything else.
>=20
> You are projecting here.
>=20
> 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."
>=20
>> 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 =
argument.
>=20
> 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.
>=20
>> one way of reading this proposal is that we don=E2=80=99t trust the =
release managers to decide what to include and not to include in a =
release.
>=20
> 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.
>=20
> 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
>=20
> "RMs Role - But they are not: Decide which features, extension or SAPI
> get in a release or not"
>=20
> Nicolas Grekas wrote:
>> Can you please let me know how that helps?
>=20
> It helps point out how obtuse you are being.
>=20
> 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.
>=20
> 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.
>=20
>> but what is "feature freeze" supposed to mean if we aren't allowed to =
discuss,
>> alter, or even revert not-yet-released features?!?
>> anything that is not yet released should be re-discussable until =
either
>> beta or RC stage.
>=20
> 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.
>=20
> 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
>=20
> cheers
> Dan
> Ack