[asterisk-dev] Time for a bug fix phase? A PLAN!
murf at digium.com
Sat May 31 22:13:12 CDT 2008
On Thu, 2008-05-29 at 11:48 -0500, John Lange wrote:
> I believe the concept of logging each channel/leg of the call would also
> fix the parking problem as well.
> A calls B. logged normally.
> B parks call. The A -> park is logged including the duration.
> C picks up parked call. A -> C is logged normally.
> As each originating channel is unbridged from something it creates a log
> file indicating what it was bridged to.
> This works for all scenarios that I can think of including 3-way
> calling, meetme, apps, etc.
I've taken the scenario that John described, and played it two different
ways, using zap/dahdi phones, whatever you wanna call them, because I
have 4 of those.
One way had both transfers via hookflash (attended), and the other did
a hookflash for the first xfer, and using the '#' to transfer the second
I then ran these 2 scenarios on 1.4, trunk, and the CDRfix5 branch.
Which made the CDRfix5 branch look real good.
But then, I ran those scenarios on 1.2, and suddenly, I looked pretty
CDRfix5 gave the same results as 1.2.
SO, here is my plan:
I'm opening two new branches, CDRfix4, and CDRfix6.
CDRfix4 will be based on 1.4
CDRfix6 will be based on trunk
I will then extract the changes made to trunk from CDRfix5, and
apply them to both CDRfix4 and CDRfix6. Just the fixes. No enhancements.
No CDR_CONTROL func. no linkedid stuff. This is intended to strictly
While I'm at it, I intend to modify the 1.4 updates to be the same
as what's in trunk. That way, when I further fix CDR problems, I will
not have to maintain two different versions of CDR systems. This
might seem a bit bold, but if I can duplicate good behavior back to
1.2, and fix all/most probs that folks saw in 1.2, then there should
be few complaints.
I'm hoping, after all is said and done, to close 12724, 11093, 11849,
And, before I commit these to 1.4 and trunk, I will definitely give
time to test this stuff, and we'll iron out any wrinkles/holes/etc you
along the way; at least to the best of my abilities. If something I did
breaks compatibility, I'll try to keep compatibility as best I can, even
if a fix means an option in a config file.
Does this sound like an acceptable plan?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080531/fcf8ae34/attachment-0001.bin
More information about the asterisk-dev