<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>To those of you who have developed code you are evaluating whether to
commit to cvs, here is information found in the new HACKING file found in the
experimental cvs directory. If you have any immediate questions or comments, I'm
all ears! </DIV>
<DIV>g-)</DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>HACKING SER<BR>===========<BR>This
information is for people who have or would like to develop a <BR>module or code
for SER and would like to submit the code to the SER<BR>CVS tree. Please first
read the README file in the experimental<BR>directory for information about the
purpose of the directory and<BR>what type of code you can
submit.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>If you have decided to go ahead, the
information below is what you<BR>need to get started!</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>Administrator<BR>=============<BR>The
administrator of the experimental directories is Greger V. Teigre.<BR>He can be
contacted at <A href="mailto:greger@onsip.org">greger@onsip.org</A>. If you have
any questions<BR>after reading this or would like to submit code, please send an
email!</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT
size=3>Registration<BR>============</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>As a new SER developer you need to
register an account at <BR><A
href="http://bugs.sip-router.org/">http://bugs.sip-router.org/</A> and at <BR><A
href="http://developer.berlios.de/account/register.php">http://developer.berlios.de/account/register.php</A>.
Use the same <BR>username for both.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>Requesting
Access<BR>=================<BR>In order to get write access to the experimental
CVS you need to <BR>send information about the module/code to the administrator
(see above), <BR>as well as your full name, and the username and email address
used for <BR>the above registration. Information about parameters and function
calls,<BR>the version of SER the module has been developed for, and one or
more<BR>use cased for the code will be of help (unless it's obvious...). You
<BR>should also include a 3-5 lines description of the code/module that<BR>you
would like to include in the experimental README.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>You will then be advised on how to
make sure your code is a use for others<BR>and if others are working
on/requested submission of similar code. The <BR>purpose of this check is to
make submitted code as easily accessible as <BR>possible and avoid overlapping
coding efforts.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>Once approved, you check out using:
cvs co experimental. You will get <BR>all the experimental modules, your
module should have an empty directory <BR>where you have write CVS
access.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>Development
Requirements<BR>------------------------<BR>You should read this general info on
the SER CVS:<BR><A
href="http://www.iptel.org/ser/cvs/">http://www.iptel.org/ser/cvs/</A></FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>And to understand how SER is
organized, you should read the first part of:<BR><A
href="http://www.iptel.org/~janakj/ser_cvs.xhtml">http://www.iptel.org/~janakj/ser_cvs.xhtml</A></FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>We strive to keep the requirements as
few as possible (we don't like <BR>overhead more than you do), but there are
some rules you must follow:</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- You are responsible for maintaining
the module for any branches you have<BR>submitted the module in. This includes
keeping it updated as HEAD and the<BR>branches are updated</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- Bug and issue tracking MUST be kept
on <A
href="http://bugs.sip-router.org/">http://bugs.sip-router.org/</A></FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- If a module is not being maintained,
it will be moved to the "attic" and<BR>eventually deleted</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- All experimental modules should be
checked in with paths as if they live<BR>in the main modules
directory</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- All experimental modules should have
an updated README</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- All experimental modules should have
#warning directives that will be<BR>shown when making, as well as a LOG(L_ALERT,
"WARNING! ..."); in the<BR>initialization function of the module. This warning
should also be added to<BR>the README file. Recommended warning template:
"This module is experimental<BR>and may crash SER or create unexpected results.
You use the module at your<BR>own risk. Please submit bugs at <A
href="http://bugs.sip-router.org/">http://bugs.sip-router.org/</A>"</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- IF YOUR MODULE REQUIRES PATCHING OF
CORE OR OTHER MODULES:<BR>If the module requires a patch to the core tree, the
README file and compile<BR>warning should explicitly warn about this and
describe how to go about<BR>patching the tree (reference to install.sh below and
README). Patch(es)<BR>should be included in a separate sub-directory called
patches/. The README<BR>should have instructions on which changes will be made,
and the maintainer<BR>should keep an updated install.sh that will apply the
patches in the<BR>patches/ directory (assuming that the module is located in the
ser modules<BR>directory after checkout by the user). This script may
include patching<BR>code in root/other modules, as well as making a new
directory in root and<BR>copying files from the modules/modulename/patches/
directory to the root.<BR>IF the contributed code is NOT a module, but a core
extension/patch, the<BR>script should make the proper tree modifications, should
NOT include a<BR>Makefile (i.e. a module makefile), and should leave its own
directory intact<BR>after patching.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><FONT size=3>- If and when the module has proven
its usefulness to a broad range of users<BR>and its stability (and the developer
his/her ability to support and maintain<BR>the module), it may be promoted to a
standard module status. This is a<BR>decision made by the core developers.
An application can be sent to<BR><A
href="mailto:serdev@lists.iptel.org">serdev@lists.iptel.org</A> if and when the maintainer
finds the module applicable to<BR>such status</FONT></DIV></FONT></BODY></HTML>