Tue, 10 Jun 2014 07:57:37 +1200
|Matt Jordan has posted an Asterisk 12 Update:|
It’s been a few months since our update on Asterisk 12, and during that time period, the Asterisk Community has been hard at work enhancing and testing Asterisk – both for existing users of Asterisk 12 as well as in preparation for the next Long Term Support release, Asterisk 13. These new features focus heavily on improving the user experience in the new PJSIP stack and enhancing the existing APIs as well as the new Asterisk REST Interface (ARI). Several of these new features have been released recently in versions 12.2.0 and 12.3.0
Thu, 17 Apr 2014 05:19:37 +1200
|The A2Billing Team has posted a note asking people to upgrade their systems urgently:|
It has been widely reported that a recently discovered bug in OpenSSL compromises the security of communications data. Any A2Billing administrator who has installed an SSL certificate to provide HTTPS encryption on their website should upgrade OpenSSL.
There is more information at http://heartbleed.com/. To check whether your site is affected, go to http://filippo.io/Heartbleed/ and enter the domain name to check.
We\'ve also had a 3rd party security expert audit A2Billing in the interests of increasing security. They have found a major security issue. We\'ve no evidence that this exploit is in the wild, but we advise in the strongest possible terms that you upgrade to A2Billing version 2.0.8 as a matter of urgency.
If you need assistance with upgrading your operating system or A2Billing or an installation with transfer of A2Billing data, then please contact us at email@example.com
The A2Billing Team.
Fri, 11 Apr 2014 05:12:38 +1200
|Matt Jordan has posted details of some changes to integration between JIRA and SVN:|
Hey everyone -
Due to a security vulnerability in JIRA, we recently had to upgrade JIRA to version 6.2. While this was a good thing (tm), it did break the snot out of the Subversion plugin. That plugin does a number of things; one of those things is auto-closing issues based on the commit message.
Traditionally, the plugin used the following nomenclature to close an issue:
(closes issue JIRA_ISSUE)
Likewise, tagging a commit with the following linked the commit message to the issue:
While I\'d like to believe the Subversion plugin will get fixed at some point, our initial forays into getting it fixed haven\'t been fruitful. Part of this is reticence on our part to \'customize\' the plugin or our JIRA instance further (more on that in a bit); another large part is Atlassian appears to be focussing on an alternate method for tying commit messages back to issues (more on that in a bit as well). Long story short, it doesn\'t appear like anyone is in a hurry to fix the old Subversion plugin.
Question: why not hack on the Subversion plugin and/or JIRA?
Answer: we could hack around on the Subversion plugin and/or JIRA (it isn\'t clear yet who is at fault), but the more customization we put into it the harder it is to upgrade the project\'s JIRA instance. This makes it harder to respond quickly to security vulnerabilities. We\'ve done a lot of work over the past year or so minimizing the customizations so that we can respond quickly to said vulnerabilities in JIRA, and it\'s been very handy. Unless there\'s a giant outcry against what I\'m about to propose, I\'d hope that we don\'t have to try and modify the plugin ourselves.
Question: what is this alternate method that Atlassian has?
Answer: Atlassian Smart Commits.
Since we have Fisheye integration with JIRA, we can use a different commit message format that will trigger the smart commits in Fisheye, which will do all of the auto-closing for us in JIRA. In fact, as the name \'smart commit\' implies, it can do a lot more than just close the issue, including leaving comments and other fanciness. It does mean however that our commit message format will have to change.
The biggest implication of changing the commit message format is making sure that patch submitters are properly attributed, such that the release summary scripts and other parts of the Asterisk project pick up who actually wrote the patch. Right now, I\'m proposing something like the following:
ASTERISK-12345 #comment patch my_awesome_fix.diff submitted by jdoe (license 12345)
You can see a commit that contains some smart commit tags in it here, which use a format similar to what is above.
What do you all think?
Digium, Inc. | Engineering Manager
Wed, 09 Apr 2014 04:27:27 +1200
|Lenz from QueueMetrics has posted a link to their free eBook on Call Center satisfaction. Sorry for the delay in getting this up:|
We are pleased to announce that our first call-centre customer satisfaction survey is online as a free eBook. We want to thank you all for supporting us in this research and answering to our questions.
According to our corporate philosophy that binds accurate data measurement to relevant business improvements, in 2013 we sent you a survey about the usage of Asterisk® and QueueMetrics™ for your daily needs in call-centers management, analysis and statistics. This was done to assess your perceived needs so that we could prioritize future improvements.
The results are quite relevant to all professionals who create or manage call-centers with Asterisk®. Too often, an Asterisk-based PBX is still perceived as a risky proposition by clients switching from other systems. But definitely Asterisk® proved to be a valid platform to build contact centres with, and grants its users an impressive level of customer satisfaction.
The survey 2014 is available for free download at http://queuemetrics.com/callcenter-survey.jsp
Do not hesitate to send us your feedbacks and suggestions. Your opinion is precious for us!
Fri, 07 Mar 2014 04:47:43 +1300
|Matt Jordan has posted details of a change to review board access:|
For some time now, the Asterisk project has used Review Board for performing code reviews on submitted patches. While having a patch be formally reviewed has never been a hard requirement for its inclusion, over time, the status quo in the project has evolved such that patches of any reasonable complexity are nearly always reviewed before being included. This is not a bad thing - code review is an invaluable tool in ensuring quality in the Asterisk project. However, some technical limitations with how accounts are configured in Review Board made it difficult for everyone to submit patches and participate in the review process. The situation today is that the vast majority of patches on the issue tracker are only looked at when they are first put up for code review. This has led to some high quality patches not being included in the Asterisk project as fast as they otherwise could.
This weekend, we finalized the integration of Review Board with Atlassian Crowd, the service that provides user identification and authentication for the rest of the Asterisk community services. This removes the bottleneck - namely, me! - that prevented any contributor from submitting patches for peer review.
For users who currently have an account in Review Board, if your username is the same as your Atlassian (JIRA) username, simply use your Atlassian password when logging in. Reviews that you currently have open will still be associated with you. If your existing username in Review Board is different than your Atlassian username, you will unfortunately need to re-open the reviews you have in Review Board. If that happens to be the case, contact me in #asterisk-dev or reply to this e-mail and we\'ll work it out.
For users who do not currently have an account in Review Board, if you signed a License Contributor Agreement in JIRA, this change opens Review Board up to you. Instructions for posting patches to Review Board can be found on the Asterisk wiki, as well as workflow guidelines for participating in code reviews. The wiki has other items to help you prepare a patch for review, including a check list of items to be aware of when performing a review or submitting a patch, as well as the project coding guidelines. Finally, because this change opens up Review Board to a much larger audience, the patch submission process has been clarified on the Asterisk wiki.
Please remember that this may greatly increase the volume of code reviews being submitted. Contributors are highly encouraged to participate in other code reviews as well, and to be patient with any submission they make. Patches that are accompanied by well written explanations, conform to the coding guidelines, and have accompanying unit tests and/or functional tests in the Asterisk Test Suite are always easier to review and will naturally move through the review process faster.
As always, thank-you for your support and participation in the Asterisk project - we hope that these changes make the process easier and more beneficial for everyone.
Digium, Inc. | Engineering Manager