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?
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. 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…) 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)... Thanks, Bob > Am 30.10.2014 um 11:34 schrieb Ferenc Kovacs <tyr...@gmail.com>: > > Hi, > > Julien an me came to an agreement to revert the recent(the remote debugging > stuff not part of any official release yet) phpdbg changes after a discussion > with Stas and David. > > We do understand that this feature is considered a pretty important and > requested feature, but we think that there are a couple of issues which > should be sorted out first. > > 1, there seems to be a disagreement about how much of our release process if > any at all applies to phpdbg or sapis in general. > 2, if we agree that our release process applies then this feature could still > be considered for inclusion because it does not breaks bc and it is a > self-contained feature and our release process allows that to be shipped in a > micro version, but only on a case by case basis, so I think that an rfc and > voting vould be approptiate here. > 3, there were some concerns about the debug protocol, and based on how much > work went into being able to build phpdbg after the recent changes (there > were like 4 issues preventing the build for multiple linux distros and even > for our windows team) multiple people expressed that they think it would > still take some time and effort to stabilize things before it could be > considered stable. (I think that at least the phpdbg webhelper ext should be > moved from sapi/phpdbg to ext/ as this trick is/was a cause for multiple > issue). > > For the record the phpdbg related changes between 5.6.2 and the current 5.6 > development branch was something like the 2/3 of the total change between > those, which is huge for a single feature in a micro release. >
