Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76185
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <53D4A9C7.8000901@lsces.co.uk>
Date: Sun, 27 Jul 2014 08:27:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <b39ebab3d19d76cda9bafa25919c0e67@mail.gmail.com>	<CAGa2bXaRgqKWG_M3n+H+=6FYqzNVE3hi3VfO8Ji1Ckf9uV+PVQ@mail.gmail.com>	<CAKOpQSxkO4xaZP=rsTwdzX6vD9b2qAkqaXCi2CC63sWPrv0J5A@mail.gmail.com>	<CAPgLKiiWCqFcZyzOAH-OaUWtwhXVi0ZicNW_2PbThbnTd6RKAA@mail.gmail.com>	<CAKOpQSy23uvHaEKoToumHkewO9Adve-zPv_c-vFwn6xUcJ9u5A@mail.gmail.com>	<a97b0acfb4c6cc2b7ad33c4fe156fb28@mail.gmail.com>	<CAKOpQSxxEzT-hhkvgeffXPtTkYFDZuws317yrECLfrZTWq+kEQ@mail.gmail.com>	<678E1F20-9F37-49DF-B48A-097B17389586@gmail.com> <CAKOpQSxMC03sRvW3CtW9c=3vCkq83Acz8vKddK0i_iz_KRm4Jw@mail.gmail.com>
In-Reply-To: <CAKOpQSxMC03sRvW3CtW9c=3vCkq83Acz8vKddK0i_iz_KRm4Jw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: lester@lsces.co.uk (Lester Caine)

On 27/07/14 07:23, Kris Craig wrote:
> Here's my question to counter yours, Michael:  What's the rush?

I think that the only 'objection' I have to 'simply' merging phpng is
that it is not just a 'single' change? This vote is all or nothing, so
every change is bundled without a vote on particular elements. That many
elements ARE simply improvements to the speed at which things   are
processed is not the problem here, and it may well be that the changes
that do affect BC have a practical justification, but there will not be
a discussion on that?

I'm currently fighting a problem due to a blanket change to a number of
systems, which offer a vast speed improvement, but now apparently make
it impossible to identify the location of the client machine. The change
to VDI is a done deal but nobody on site seems to be interested in
fixing the resulting problem :( Due diligence would have addressed the
problem beforehand and could well have steered things a different way.

The 'rush' with phpng is that people need to have a stable base to be
working with, and if php-next is to be phpng, then we need to be working
with it. If I magically found some spare time today should I be looking
at the current code base or phpng going forward? Documentation IS
crucial here, and documenting those changes and providing information
where an individual change affects BC  is essential, but there should be
some mechanism to review elements that are not so clear cut? IS_BOOL
object container against IS_TRUE and IS_FALSE new values is probably not
a good example, but it is a change that I don't currently see full
rational behind ... if I create a bool container I don't know which
value it is ...

We do not want to complicate things by voting on each element, but it's
the simple fact that so many elements have been re-engineered without
the normal process that is causing irritation, so some agreement that if
questions are raised about an element then it WILL get a proper
discussion and if justified get reverted? I think that this is part of
the debate on 2/3rds or 50-50 ... there are elements which would
normally be a 2/3rds decision? So there should be an agreement that
these can be reviewed again later?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk