Summary:	ASTERISK-03658: 1.0.7 Release Candidate - Please test and report!
Reporter:	Russell Bryant (russell)	Labels:
Date Opened:	2005-03-09 13:04:53.000-0600	Date Closed:	2005-03-19 00:37:08.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	We are ready to release 1.0.7 but need some people to test and verify that the code is without any major bugs. Please grab the latest code from stable CVS (cvs co -r v1-0 asterisk). Once I get enough comments here that the code is working without problems, we will release 1.0.7. ****** ADDITIONAL INFORMATION ****** Disclaimer is on file :)
Comments:	By: eko1 (eko1) 2005-03-09 15:00:23.000-0600 It works, except for the fact that I had to delete almost all of the stuff in my modules directory prior to doing 'make && make install' (the loader would complain about missing symbols when I started Asterisk). edited on: 03-09-05 15:01 By: drmac (drmac) 2005-03-09 15:11:23.000-0600 did u do a "make clean" before-hand? might have fixed that problem.. By: eko1 (eko1) 2005-03-09 15:15:31.000-0600 Yes I did. Didn't fix it. That's why I had to delete most of the stuff in the modules/ directory. By: Joshua C. Colp (jcolp) 2005-03-09 15:25:48.000-0600 Did you happen to downgrade from CVS head to a CVS stable, as above is mentioned? If so, then CVS head modules were present and they are unable to be used in a CVS stable environment. Thus, if doing above make sure to rm -rf /usr/lib/asterisk/modules to get rid of the modules. Thanks for your feedback though, it's appreciated - drumkilla says thanks too. Everyone - continue to test and post comments. By: eko1 (eko1) 2005-03-09 15:34:57.000-0600 Yes, I did downgrade from head to stable. It all makes sense now. Thanks. By: Joshua C. Colp (jcolp) 2005-03-10 13:58:25.000-0600 This was tested at the Digium/Asterisk booth at VON and it worked great. Music on hold is fixed in this revision, and all normal features are working as they should. Everyone else should test and continue to report. By: damin (damin) 2005-03-10 17:57:24.000-0600 I will be rebuilding my home pbx this weekend after I get back from VON. It is my intention to install and run the 1.0.7 branch on that box. I will be testing IAX2 trunking, voicemail, SIP and codec translation from ulaw to gsm, g726 and ilbc. By: Jared Smith (jsmith) 2005-03-10 18:39:58.000-0600 Please add the patch in bug ASTERISK-3600... While it's not that important, it does fix a broken application, and does not add any new functionality. By: Russell Bryant (russell) 2005-03-10 18:48:33.000-0600 Well, if it makes it into CVS head in time, then we can consider it.  I don't put any patches like that into the stable branch until it has been resolved for CVS head. By: dougmeredith (dougmeredith) 2005-03-10 18:57:56.000-0600 You need to have a cut-off at some point.  If you are asking people to evaluate a release candidate, then it is too late to put more things in.  Any change you make at this point invalidates all testing that has been done.  You never know what unexpected side-effects there might be from even a simple change. By: Russell Bryant (russell) 2005-03-10 19:11:51.000-0600 Well ... if it's an application that is totally broken, then I would not say it is out of the question. By: dougmeredith (dougmeredith) 2005-03-10 19:38:16.000-0600 I hope I'm not stepping on anyone's toes here.  This isn't an absolute,  just my view. It seems to me that before a release candidate is declared, a decision should be made on which known bugs will be included.  Obviously unkown bugs discovered after the candidate is declared might be reason for another candidate.  If there are known bugs that are being considered for the release, the release candidate shouldn't be created until they are either included or ruled out.  Otherwise people are just wasting their time testing something that isn't going to be released anyway. By: Russell Bryant (russell) 2005-03-10 20:14:33.000-0600 I agree with you.  I don't plan on making any changes to any major parts of the code.  There are other bugs that could have been included but I don't plan on addressing until after 1.0.7.  For example, there are some connectivity issues with ODBC that are going to take some extra work. The patch we were discussing is in reference to one little application.  The problem causes it not to work at all.  If I make a change, testing will be required for that one application, but that does not void the testing done on everything else. I don't disagree with anything you had to say, I just don't think that this specific case is that big of a deal.  In any case, I don't think it is going to be resolved in time, so we probably don't need to worry about it. By: Kristopher Lalletti (kris2k) 2005-03-11 08:28:30.000-0600 I just compiled it this morning to find that my MOH works with G729-uLaw transcoding!. Bug ASTERISK-3643677 should be added to the 1.0.7, since it involves the ACD and its configuration parameters that are not respected for a certain call scenario. Aside from that, Bug ASTERISK-2872905 would be a nice icing on the cake. Since, it completes the implementation of the Macro parameter in app_dial. Since, we all must be able to pass parameters to macros, or else it defeats the purpose of using them. edited on: 03-11-05 08:35 By: Russell Bryant (russell) 2005-03-11 10:55:43.000-0600 In reference to bug 3677, I am going to include it, but I think it is too late for 1.0.7.  I would rather leave more time for testing that change, and I'm trying to get 1.0.7 out as soon as possible because of the known issues in 1.0.6. In reference to bug 2905, I have a general rule to try to only include bug fixes into this branch of the code.  You can work around that by just using channel variables. By: Jared Smith (jsmith) 2005-03-12 14:21:12.000-0600 Bug 3681 has been now been fixed in CVS HEAD, and also contains a patch for STABLE.  Now that it's in -HEAD, will you consider it for the 1.0.7 release? By: Donny Kavanagh (donnyk) 2005-03-16 15:49:40.000-0600 Whats going on here, no updates in 4 days. Everything looks ok for me with 1.0.7RC here... no problems that i've noticed. By: damin (damin) 2005-03-16 16:05:57.000-0600 Alright. I updated my Development and Home PBXs to 1.0.7 w/ Slepp's Dundi 1.0.2_diff-4 patch. Both are running solid. One issue that I noticed is that my Polycom SP IP phones had to be changed to use RFC2833 signalling instead of the Inband signalling I had been using earlier. I simply modified the sip.conf to have "dtmfmode=rfc2833". This proved to be a slight gotcha for a couple of clients when I updated THEIR boxes. This could be just a fluke, and I may be an idiot for having used inband DTMF in the first place, but it is something to be concious of. Can anyone pinpoint a specific SIP patch that may have been applied where this may have been affected? How should this be handled? Should I add it as a new bug-note? Or should we just chalk it up and slap a notice in the release notes? Should inband signaling be broken in 1.0.7 for Polycom phones? Or should it work? I guess this is the question that needs to be asked.. is it normal behaviour or a bug? I'm not sure if this is related, but I also enabled MMX math routines for Zaptel. By: damin (damin) 2005-03-16 16:26:12.000-0600 I reopened http://bugs.digium.com/bug_view_page.php?bug_id=0003681 and have uploaded a corrected patch that applies cleanly to the release candidate. I'd like to have some independent feedback verify that it is correct, and would request also that 3681 be committed to CVS before 1.0.7 is released. By: Russell Bryant (russell) 2005-03-16 18:36:54.000-0600 That module was written for CVS head, so it won't work with the 1.0 branch.  When installing 1.0, please remove all modules from /usr/lib/asteris/modiules/. I added the patch for bug 3681, and 1.0.7 will be out as soon as possible. As for the SIP problem, I'm not sure what to say.  I don't have any SIP phones for testing.  :(  Have you tried it with CVS head?  I'm not sure what could have caused it.  It's better to do out-of-band, anyway.  If you find anything, let me know. Thanks to everyone who has provided feedback.  I surely can't do all of the necessary testing on my own. By: Fernando Romo (el_pop) 2005-03-16 19:45:00.000-0600 Be aware of the bugs ASTERISK-3563590 and ASTERISK-3713748 than produce crash in asterisk system before release 1.0.7, are present in CVS Head and could compromise * stability edited on: 03-16-05 22:20 By: Russell Bryant (russell) 2005-03-16 22:18:54.000-0600 Those are likely only bugs in CVS head. By: damin (damin) 2005-03-16 22:35:13.000-0600 Are we sure of that? Even after reading both of the bugnotes, I can't really get a handle on what I would need to do to even test and see if the problems were reproducible. I certainly can do this, tonight even.. If someone can give me some direction on what to do, I can verify wether this is a problem for Stable. I've got Grandstream, Cisco and Sipura SIP gear here at my house. By: damin (damin) 2005-03-17 16:47:51.000-0600 According to Mark and BKW from the Developer conference today, 3590 and 3748 might already be fixed in CVS Head, and even so, should NOT affect Stable. As such, I would say we can safely ignore these unless someone w/ more skill than I can replicate the behavior. By: Russell Bryant (russell) 2005-03-18 11:41:06.000-0600 I just made a change so that a box running 1.0 would not explode if a box running CVS head sends it timestamps on trunk frames. It's a fairly simple change, but it would still be nice to have someone verify that IAX trunking still works as expected (not using the timestamps, of course). By: Russell Bryant (russell) 2005-03-19 00:36:58.000-0600 Ok.  1.0.7 is out! Thanks to everyone for providing feedback and testing support!