Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120251
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6
Mime-Version: 1.0
Message-ID: <5df93d0c-5f86-4deb-887f-fb14efc83a8b@app.fastmail.com>
In-Reply-To: <58ace15d-ae0b-784b-23e3-7eeda6578680@heigl.org>
References: 
 <CAEKnhAEzEBRHO+=3KSLCveEWZ7ZwxtD0MJL-=VG6nz2xMcvbMA@mail.gmail.com>
 <CAEKnhAGYJJNSW=8ir2n56SP_Kh+nT0L33i+EN=oeD1JNx76kgA@mail.gmail.com>
 <f271b714-e1a4-4b0c-9402-6fb84c28ca6b@app.fastmail.com>
 <68bd0906-40ec-9e30-67ad-d4af881eb480@heigl.org>
 <CAL0xaBFuAtg1xmsUy_mV9Zia0T5sG2JcDWsEkHU5U6QmEHrKOg@mail.gmail.com>
 <58ace15d-ae0b-784b-23e3-7eeda6578680@heigl.org>
Date: Fri, 12 May 2023 18:01:02 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, May 12, 2023, at 4:10 PM, Andreas Heigl wrote:
> Hey Arvids, Hey all

>> In the modern day, people expect a very different style of communication.
>> And, sadly, those are the people who make decisions like "should we abandon
>> PHP and move to Go or JavaScript" and so on.
>> The other part that irks me a lot how php.net is developed - while it is
>> fine and it works, I have seen people lose all interest as soon as they
>> open the code. Nobody wants to touch it. And nobody wants to be responsible
>> for it too as far as I can tell.
>> The windows build machine.... I really don't have to explain anything here,
>> do I?
>> 
> Larry asked what alternatives those who voted "No" see.
>
> My main topic that I seem not to have been able to get across is that to 
> me there is no need to implement alternatives as everything is already 
> there.
>
> * We have rules for the list.
> * We have a workflow that should prohibit stuff getting into the core 
> from new developers without at least a second set of eyes and in case of 
> strong disagreement a separate discussion
> * We have an elected group of people that has the say about the part of 
> the source that they are responsible for

So you're basically arguing that it's an "implementation problem", not a rule problem.  I cannot agree.

Primarily because this

> * We have a workflow that should prohibit stuff getting into the core 
> from new developers without at least a second set of eyes and in case of 
> strong disagreement a separate discussion

isnt' true.  We have a workflow for new functionality that warrants an RFC.  "What should the process be to re-optimize the way C includes work" is not something the RFC process is in any way suited for.  That sort of decision *needs* to have a clear voice on it, from some small, mostly agreeable set of voices.  (Which, again, does not include mine.  That's the point.)

That is a process gap right now, and it leads to other problems.

Expanding the role of the Release Managers to include that responsibility is one possibility.  I would be open to that, if others (including the RMs) are.  However, for that to work, we'd need to elect RMs much sooner, say, October/November range so that they're ready to "take over leadership of HEAD" as soon as the branch is open for development.  Maybe sooner.

This is an approach I'm open to exploring, but as noted, would be  a scope change and rule change for the RMs.

--Larry Garfield