Re: Re: phpdbg situation in PHP-5.6

> Am 30.10.2014 um 19:23 schrieb Stas Malyshev <smalyshev@sugarcrm.com>: > > Hi! > >> An alternative would be just putting a few #if 0 in code >> (phpdbg_out.c where the outputting of anything is centralized) to >> make XML stuff not usable. Maybe that one is the cleanest and least >> invasive with still allowing us to change the whole XML stuff. And at >> the same time the normal improvements would still go into 5.6.3? > > Hot-patching with if-0's is not how things should be done in stable > branch. If the code is not ready for prime time - which is obviously the > case here - it should be developed - and tested! - in the feature > branch. Then merged to master. And only then, after proving working - > wait for it - put to discussion on internals about getting it into > stable branch. Dumping it into a stable branch and hoping "maybe we get > lucky and can get it into the next release" is not how release > management should be done. Stable branch is called "stable" for a reason. > This is not something critical that we have to release ASAP or the world > burns. It's not a security fix. It's not even a critical feature > millions asked for for years and this is the only chance to get it in. > There is absolutely enough time to do it right. So let's do it right. That’s why we have reverted it totally now for 5.6.3 rc. I’ll now patch with if-0’s the current controversial things for being able to work on them and eventually extract them completely out if not wished - before 5.6.4 rc. I’m going to set up some RFC, but first I need to talk to Derick to resolve misunderstandings and maybe look at how to proceed. >>> 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. > > And that's exactly the point. It's not your failure. It's nobody's > failure. That's how the software world works - you can not foresee > everything. You have to test. That's why we do not start with merging > into the stable branch a day before the RC. It's not because somebody's > code is particularly bad. It's because the release practices are the > result of experience - if you don't do it, you *will* have trouble about > which you had no way of knowing. By the way, it was merged in last weekend, not just the day before RC. But true, I’m a bit impatient… I should work on myself in this regard… > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > <http://www.sugarcrm.com/> --- Bob Weinand