Good afternoon Joe, On Sun, Sep 15, 2019 at 12:48 PM Joe Watkins <krak...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
