[Xorp-hackers] how to distribute a new XORP release
Pavlin Radoslavov
pavlin at ICSI.Berkeley.EDU
Thu May 22 13:31:47 PDT 2008
李彬 <libin020989 at gmail.com> wrote:
> I'm a student from Beijing University of Posts and
> Telecommunications.Huawei company submited a
> LightWeight-IGMPv3/MLDv2 draft,it was accepted by IETF.IETF hopes
> Huawei distribute the source code.The development of the source
> code was done by us.We modified the IGMPv3/MLDv2 module which is
> in the XORP release 1.4.I want to know whether we can distribute
> it on the XORP website as a new XORP release and how to distribute
> it.
We looked into the source code with the modifications that was
submitted to Bugzilla:
http://bugzilla.xorp.org/bugzilla/show_bug.cgi?id=756
As you know already, XORP has the full IGMPv1,2,3/MLDv1,2
implementation. The Lightweight IGMPv3/MLDv2 version of the spec
(I-D draft-ietf-mboned-lightweight-igmpv3-mldv2-02) actually removes
functionalities from the full IGMPv3/MLDv2, therefore it has little
practical value for XORP.
We understand however, that someone looking specifically for a
reference implementation of "Lightweight IGMPv3/MLDv2" might benefit
from your code.
For that reason, we could add a copy of your code to the xorp/contrib
subdirectory. However, the tarball in Bugzilla as-is cannot be added
to the CVS tree.
If you would like your code to be added to
xorp/contrib/mld6igmp_lite you should do the following:
* You need to apply your changes to the latest XORP code from CVS:
http://www.xorp.org/cvs.html
What you are using right now is XORP-1.4 and there have been a
number of modifications since them.
If you do "diff -ur mld6igmp contrib/mld6igmp_lite"
you should see only those changes that are related to the Lite
version of the protocol with no side effects
(e.g., no line formatting, leftover temporary comments, etc).
In fact, this will be the command we will be using to evaluate
the next tarball from you.
* Cleanup the code.
Right now there are a number of leftover XLOG messages like the
following that should be removed:
XLOG_WARNING("RX kakalong 333333333333322++++...")
If you want to have log messages that can be enabled in run-time
then you should use XLOG_TRACE().
If you want to have log messages that can be enabled in
compile-time, then you should use the debug_msg() mechanism.
Regardless what mechanism you use, the text of the log message
should be clear and meaningful.
Comments like the following should be removed as well:
//Modified by ... 06-13. mark:not needed modification
There are other comments with modification summaries that don't
need to be in the final code:
/*
* modified verion: 1
*
**********************************************************************
* modified Summaries: delete _dont_forward_source_list relevant variables
* There is a local logging implementation inside your code (class
LocalTrace and friends) that should be removed.
There is no obvious reason why this should be there instead of
using the existing XORP XLOG mechanism.
* It doesn't seem that the modified code is following the XORP
coding style (available from xorp/devnotes/coding-style.txt).
E.g., lack of space after "," argument separator, long lines
without a break in the appropriate place, etc.
* If the code is added to xorp/contrib/mld6igmp_lite, there should
be instructions (in your own README that will be included with the
code) how someone would use it instead of the full IGMP/MLD
implementation from XORP.
For example, if you provide your own *.tp or *.cmds rtrmgr/xorpsh
template files, there should be instructions how someone would use
them to replace the existing IGMP/MLD-related templates.
Also, obviously, there should be instructions how someone to
compile it (e.g., using "./configure --enable-mld6igmp-lite"
configuration switch).
* In your README there should be contact information for those of
you who will support the code (dealing with bug issues and
updates, major compilation issues, etc).
As a policy, if a third-party module no longer builds against the
current XORP code or has significant bugs and has not been updated
in 6 months, then the code will be moved to a separate
"obsoleted code" repository.
Please let us know if you have any questions.
Thank you,
The XORP team
More information about the Xorp-hackers
mailing list