On Thu, Oct 30, 2014 at 11:59 AM, Bob Weinand <bobw...@hotmail.com> wrote:

> Hey, I can accept that.
>
> But it’d be great if you could only revert now in the 5.6.3 release
> branch, not in the 5.6 development branch, so that this gives us now still
> some time to see what exactly we want to revert or not and for some
> eventual RFC?
>

we could do that, but that will make the RMs job much harder, because that
means that any upcoming 5.6 rc/stable release has to be always cherry
picking everything but the phpng stuff.
I think having it in the krakjoe/phpdbg repo, or in php-src but under a
feature branch would be better.


>
> To add for 3.: Issues where with what I really couldn’t think of (separate
> build dir on Linux…) or the issues with a JSON dep or Windows which I
> couldn’t test.
>

yeah, sorry if it sounded as I'm blaming you guys, I was trying to make a
point about that big changes like that need some time to stabilize and I
also think that some of the issues would have been pointed out if there
would be some discussion prior merging a bunch of changes to php-src.


>
> Also, just to point it out: Windows allows extensions to be in a random
> directory, *nix does not. I’d rather change the /acinclude.m4 to not be
> bound to the /ext directory, so that it just works like on Windows.
> (That ugly hack really annoys me too…)
>

I could live with that, but we have to be careful when changing the build
infrastructure, because people build php on more platform than we test on.


>
> It wasn’t also a single feature, but more features (though XML protocol
> could be well be the cause of 1/3 of the lines changed in phpdbg)...
>

fair enough.
is there any change which is not related to the remote debugging/new xml
protocol and you would want to have it in 5.6.3?
We are getting late with the tag, so my quick solution would be reverting
everything phpdbg related from PHP-5.6 in the last 5 days or so.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Reply via email to