[asterisk-dev] Time for a bug fix phase? A PLAN!

[Steve Murphy]

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.
> 
> Regards,

John, Greyman--

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
time.

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
bad.

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
be fixes.

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 10927.

And, before I commit these to 1.4 and trunk, I will definitely give
you-all 
time to test this stuff, and we'll iron out any wrinkles/holes/etc you
find
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?

murf




-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080531/fcf8ae34/attachment-0001.bin