[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