Re: com php-src: Bug 49898 __getCookies() method implementation: ext/soap/soap.c ext/soap/tests/bug49898.phpt

I'm moving the discussion to internals@, here is the context those who didn't get the original mail: http://news.php.net/php.cvs/78956 On Thu, Jun 19, 2014 at 2:38 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > Hi! > > > This is indeed a trivial and self-contained feature, but I think that > the "on a case by case basis" from > > https://wiki.php.net/rfc/releaseprocess > <https://wiki.php.net/rfc/releaseprocess> should also > mean some prior > discussion on the list. > > This one looks rather trivial but if you see a need to discuss some > objections we can discuss them. > I don't have any technical issues with this change, and I also consider it self contained and only introduces a single method for an already existing class, so it keeps BC in the strict sense (as opposed to introducing a new constant/class/function could conflict with something defined from userland with the same name). As I mentioned my only problem is that we can't have feature freeze in 5.6 for example as long as we just merge everything upwards from lower branches.. > > > My biggest issue is that allowing to frequent feature introduction > into stable branches means that we can't really have > > It's not frequent at all. For the last 10 releases I can count barely > half-dozen additions. > This particular issue was filed 4.5 years ago and the pull was sitting > there for almost a year. I think it's enough time to wait for a trivial > and uncontroversial patch to get in, but if I'm wrong it's not too late > to discuss it. Again, I'm not advocating the general approach of commit > first and ask later, especially for substantial changes, but this was > out there for a long time and I don't see why anybody would object to it. > sounds fair. > > > feature freeze in a development branch, because it would make no sense > to have a new feature in X.Y.Z which isn't > > present in the X+1.0.0, even though that the latter was release later. > > I'm not sure this minor thing qualifies as "feature" really, but if it's > a problem we can hold adding even a minor stuff for a while. I wouldn't > want to do it for a long time though, our turnaround time are already > not that great and pulls are sitting for months without anybody looking > at them. So when I have some time to look at them I'd like this time to > be productive. If you have any suggestions on how to improve the process > I'd be glad to hear them. > > We can either: 1. keep doing what we are doing right now, and accept that it can happen than a small feature is introduced at any time. 2. make it a policy that we hold back changes like that even from the lower branches, when a development branch is under feature freeze. 3. when a branch is under feature freeze, the RMs should stop merging from the development branch to the release branch, and start chery-picking instead (afair this is what we do for the release branches of the stable versions), but as I mentioned this has the side-effect that a feature already present in a lower version could be missing from release of the higher version done afterwards. Personally I think that 1 would be acceptable if we can keep these feature introductions as rare events, 2 would be a somewhat arbitrary restriction, and 3 could be confusing for the early adopters(slow adopters wouldn't really realize that the 5.6.X version missing feature Z was released after 5.5.Y which has the feature, so they wouldn't have expectations), -- Ferenc Kovács @Tyr43l - http://tyrael.hu