Second Half of Kevin's Presentation
-Extreme code review has begun
There are now various people assigned to parts such as commenting, clean code etc
Coding Guidelines:
Can be found in /usr/src/asterisk/doc/CODING-GUIDELINES
If you are changing a module and see that some things are not complying with the guidelines, please submit a patch which ONLY contains the fixes for guidelines first
-Code is generally formatted in same way as the Linux Kernel
-Do not add comments that do not provide direct value (I.E. look at this cool thing I did!)
-Do add comments for things that are not obvious
-Code should have functions that are as short as possible (app_voicemail3 could be written if you like)
-Make liberal use of the operators, statements and block types that C offers
-Function Modules can be named anything you like except they cannot start with 'ast_'
-Functions that are intended to become part of the API should be started with 'ast_' and the prototype MUST be added to the relevant header file in include/asterisk
-Global variables in modules should be named with the 'global_' prefix
-Others should be descriptively named
-Variables exposed outside the module (which should be kept to a minimum) must be named with the 'ast_' prefix
-Remember that Asterisk works on at least 4 operating systems and multiple CPU architectures. Changes should not be platform or CPU specific
-Do not use obscure language, library of system features just for the sake of using them. If it increases performance or maintainability benefit can be demonstrated.
-Document your code so that it can be used with doxygen
-Modules that use a new config file should include a sample config file
-Use IRC, Mailing Lists (Asterisk-Dev, Asterisk-CVS) and the Bug Tracker
-The future may include: Changes to The Asterisk Object Model, Asychronous Event System (for internal modules, in a similar way to the Asterisk Manager Interface works)
-Things in the source will be changing rapidly.
-ALWAYS check #asterisk-bugs (on irc.freenode.net) first before submitting a bug to be sure that the bug report is all correctly filled out.
-People should watch the bugtracker to see when they can help with testing. Also, please post your comments. This will really increase the speed with which fixes are applied
-IAXTel is back up (and has around 10,000 users registered, with 1000-1500 at any given time. It is an average PC with a single processor
Support Zoa's work for increasing the capacity of Asterisk
There are now various people assigned to parts such as commenting, clean code etc
Coding Guidelines:
Can be found in /usr/src/asterisk/doc/CODING-GUIDELINES
If you are changing a module and see that some things are not complying with the guidelines, please submit a patch which ONLY contains the fixes for guidelines first
-Code is generally formatted in same way as the Linux Kernel
-Do not add comments that do not provide direct value (I.E. look at this cool thing I did!)
-Do add comments for things that are not obvious
-Code should have functions that are as short as possible (app_voicemail3 could be written if you like)
-Make liberal use of the operators, statements and block types that C offers
-Function Modules can be named anything you like except they cannot start with 'ast_'
-Functions that are intended to become part of the API should be started with 'ast_' and the prototype MUST be added to the relevant header file in include/asterisk
-Global variables in modules should be named with the 'global_' prefix
-Others should be descriptively named
-Variables exposed outside the module (which should be kept to a minimum) must be named with the 'ast_' prefix
-Remember that Asterisk works on at least 4 operating systems and multiple CPU architectures. Changes should not be platform or CPU specific
-Do not use obscure language, library of system features just for the sake of using them. If it increases performance or maintainability benefit can be demonstrated.
-Document your code so that it can be used with doxygen
-Modules that use a new config file should include a sample config file
-Use IRC, Mailing Lists (Asterisk-Dev, Asterisk-CVS) and the Bug Tracker
-The future may include: Changes to The Asterisk Object Model, Asychronous Event System (for internal modules, in a similar way to the Asterisk Manager Interface works)
-Things in the source will be changing rapidly.
-ALWAYS check #asterisk-bugs (on irc.freenode.net) first before submitting a bug to be sure that the bug report is all correctly filled out.
-People should watch the bugtracker to see when they can help with testing. Also, please post your comments. This will really increase the speed with which fixes are applied
-IAXTel is back up (and has around 10,000 users registered, with 1000-1500 at any given time. It is an average PC with a single processor
Support Zoa's work for increasing the capacity of Asterisk
posted by Dal at
11:17 AM
