Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107148
MIME-Version: 1.0
References: <CAOwTYAu5vCGMw4Dp0v90fGD9OGm6X0dc42iJV35bk1Df_yr_2w@mail.gmail.com>
In-Reply-To: <CAOwTYAu5vCGMw4Dp0v90fGD9OGm6X0dc42iJV35bk1Df_yr_2w@mail.gmail.com>
Date: Mon, 16 Sep 2019 15:29:48 +0700
Message-ID: <CAEZPtU7+6iTTNzSe+1Afq7YgwEF2_moW_Nmb+CRxMQfrYpgt8A@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP internals <internals@lists.php.net>, Rasmus Lerdorf <rasmus@php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Defining the PHP Group
From: pierre.php@gmail.com (Pierre Joye)

Good afternoon Joe,

On Sun, Sep 15, 2019 at 12:48 PM Joe Watkins <krakjoe@php.net> wrote:

> There is confusion among the community, and contained in the documented
> history of PHP on the wider internet.
>
> The Wikipedia states that PHP is developed by the PHP Group, in saying this
> it is (must be) referring to internals as a whole, but our own
> documentation names members of the group - who aren't even around mostly.

The wording there is wrong, that could be fixed.

Many are still around. But that does not matter much in this case. See below.

> I think we need to clarify what exactly is the purpose of the PHP Group
> today, does anyone want to attempt to do that ?
>
> Whatever it's purpose, if it has one, we need to make clear at this time
> that there are no vetos: As Rasmus clarified, PHP is driven by the people
> who write PHP: No member of any group or company, historical or otherwise,
> has any veto powers, they cannot, and they must not behave as if they do.

The RFC process defines a veto and could be applied when needed.
Luckily it never happened. That does not mean it can never be applied,
there are cases where it will happen, by default.

> I would like to update the introduction to the Voting RFC:
>
> The development of PHP is community driven by the RFC process described in
> this document. Anyone may initiate an RFC for any subject. At the end of
> the RFC process a vote is held among PHP developers to determine if the
> proposal is to be accepted.

Licenses changes, licenses (c) and related areas cannot be done via
RFCs, at all. While the PHP Group solution is not ideal, it is/was the
less cumbersome one we have as of now.

We also discussed many times if having a foundation could help, which
allows more changes easily but it was never considered worth it as a
non invasive, mostly neutral group, works just fine. A foundation is
really hard to create (where? US? EU? Other?), how would be the board
elected? who will fund it? Which model? Apache? .net? Other? This is
not something that can be done via a RFC.

> Should a proposal be accepted, the developers of PHP are committed to
> making the change.

A blatantly wrong proposal introducing major flaws in the languages
could be vetoed as that is why the veto clause was introduced (f.e.
impacting massively the security or the performance of the language).
As mentioned already, it luckily never happened.

> Should a proposal be accepted without an implementation, it is the
> responsibility of the proposer to provide one.
>
> Does anyone object to any of those words ?

> Do we need to vote on changing the introduction (I'm happy to start an rfc
> for this, if necessary) ?

I am not sure changing the words will affect these cases. We do need
more clarity, that is a sure thing, but we do have to be clear about
what is possible and what not.

Also on a side note, I have lived 4 major versions and every single of
them has been a mid life crisis situation for the PHP project. This is
something I would like (no idea how) to address. My key point since at
least after 5 is that we can decide to do one anytime we want. And all
these discussions could be much more smooth if we could keep that in
mind. F.e. each of them had major focus, either OO introduction,
rewrite of the engine (happened 2-3 times before) are some of the
focus major versions had. Everything else are bonuses. In short, the
main issue I can see is the feeling that we won't have another major
version in our lifetime, which is wrong. Some new joiners may see it
like this as they only know 7 since they joined with 5.x (as an
example). Last but not least, this lack of focus was what killed php6
and created the first major crisis in the php project and costs us
some of the core team (who left afterwards, be because of this or
because this failure was the drop too much).

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org