Re: Re: [VOTE] PHP Technical Committee
| From: | Larry Garfield | Date: | Fri, 12 May 2023 18:01:02 +0000 |
| Subject: | Re: Re: [VOTE] PHP Technical Committee | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120251@lists.php.net to get a copy of this message | ||
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