Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74499
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <44A0430A-9E30-43B7-855F-23ACC5FE0E81@ajf.me>
References: <CAMUwpuSanG7cacWS_3_sLCBkV2bDhDaZOkaQbQaHejGL75qJrA@mail.gmail.com>
	<44A0430A-9E30-43B7-855F-23ACC5FE0E81@ajf.me>
Date: Mon, 26 May 2014 12:59:27 +0200
Message-ID: <CAEZPtU740GGCqfDV2x6NZwgFvrrE7x9V6-3n6dHTCKaSNkiNxw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Documenting APIs and merging ideas
From: pierre.php@gmail.com (Pierre Joye)

On Mon, May 26, 2014 at 12:52 PM, Andrea Faulds <ajf@ajf.me> wrote:
>
> On 26 May 2014, at 11:37, Julien Pauli <jpauli@php.net> wrote:
>
>> If some start hacking based on master, they'll hit problems the time
>> phpng gets merged (if it is to be merged). And the same applies
>> reversed : how can phpng contributors integrate in their branch ideas
>> from other developers and branches ?
>> Wasn't it the case for the int64 patch from Pierre ?
>
> This problem has been bothering me as well. There=E2=80=99s stuff I=E2=80=
=99d like to =E2=80=94 or at least attempt to ;) =E2=80=94 do in Zend, but =
phpng isn=E2=80=99t merged yet so I fear having to redo much of it once it=
=E2=80=99s merged.
>
> I suggest we only work on stuff which won=E2=80=99t touch Zend, or at lea=
st won=E2=80=99t touch stuff phpng touches, until phpng is merged. However,=
 this is assuming phpng won=E2=80=99t take too long.

Nice concept but due to its nature, phpng touches everything. Every
single LoC related to zval, hash, or string are affected by the
changes in phpng. The 2nd question is how to do not loose too much
time until phpng gets some momentum. It will remain a moving target
for the coming months (6+), can we afford to simply do almost nothing
in the core from a design (APIs, cleanup, etc) for php 6 until phpng
will be less than a moving target? Let alone RFC ready? I am not sure.

I am not sure either about how to allow everyone to work on phpnext
while stopping one team or another, right now it is all about
performance, with promising results. While my personal priority would
be rather to clean up the code base and the APIs along other things.
No matter how, conflicts will happen. I tend too think that phpng
should have more branches with individual changes, which can be merged
to master individually. I can hardly think that having a bunch of mass
changes being proposed in one go (the zpp change is a very good thing
f.e., from a process pov).

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org