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

[Steve Murphy]

On Mon, 2008-06-02 at 23:24 -0500, John Lange wrote:
> The plan sounds good to me. I will be more than happy to test the
> CDRFix4 branch.
> 
> One question; where is it branched from? Question being, is it branched
> from a "stable" 1.4 meaning I could potentially put it into production
> at the client that is complaining the loudest about the CDR issues? I
> would think CDR fixes shouldn't cause any instability?

CDRfix4 is branched from 1.4 directly. It's the proto for the next 1.4
release, which will come whenever the next set of changes or security
fixes, or whatever, seems to make it a good time to make a new release.
I have autoupdate set on the CDRfix4 branch, so it should be kept up
to date fairly automatically, with some hours of lag-time.

And, Hey, remember, this is a test branch. No, it's not guaranteeing
anything.
It could crash, muck up CDR's, and make life miserable for both of us.
So, I'd not advise you to unleash it on your clients until you feel warm
and fuzzy about it. If you find problems, either report them here or
in the bug tracker. I have hopes of solving any problems swiftly. We
shall see about that, tho.

I've noted that I did very little to the sip channel driver. So, there
may be issues to solve there... let me know.

> 
> One thing I'm not clear on is if you meant this branch was ready to be
> tested now? Or are you going to post when it's ready?
> 

I have updated the CDRfix4 branch and it's ready to test now. I ran two
versions of your scenario thru it and the result compares to 1.2 almost
to the byte.

The first of the two versions of the scenario used hookflash twice; the
second used a hookflash for transfer from B to C, and '#' to xfer from 
C to D. I've got a file showing all the detailed steps, and what the
results were from 1.2 to 1.4 to trunk to CDRfix5. Again, I did my
testing
using zap/dahdi phones, because I have 4 of those.

I'm sure there will skips, holes, and gaps, but hopefully we can plug
those
and get results as good as, or better than, 1.2.

> > > 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.
> 
> As far as a "fix" strategy I think you are definitely on the right track
> with that plan. Having 1.4 CDRs that are at least as accurate as 1.2 is
> a great starting point and since those fixes can be pushed forward into
> 1.6 as well this is all good.
> 

I had a little AEL complaint to fix, but I'm back into this, today I'll
be 
trying to merge the CDRfix5 stuff in CDRfix6 for trunk.

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/20080603/28ad5f0a/attachment.bin