--- a/BUILD	Thu May 17 07:51:22 2007 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,182 +0,0 @@
-If you want to build ns3, you need to install scons (see
-http://www.scons.org). scons takes care of building
-the whole source tree using your system compiler. scons
-0.91.1 and 0.91.96 have been tested and are known to 
-work on linux FC5, Mac os X and MinGW.
-
-To start a build, you can just type 'scons' which
-will generate a debug shared build by default, located
-in the directory 'build-dir/dbg-shared/bin' and
-'build-dir/dbg-shared/lib'.
-
-All builds are built with debugging symbols. Debugging
-builds enable asserts while optimized builds disable them.
-On platforms which support it, rpath is used which means that
-the executable binaries generated link explicitely against
-the right libraries. This saves you the pain of having to
-setup environment variables to point to the right libraries.
-
-1) Options
-----------
-
-- verbose: if you have installed scons 0.91.96 or higher, 
-  the default build output is terse. To get a more verbose 
-  output, you need to set the 'verbose' variable to 'y'.
-Example: scons verbose=y
-- cflags: flags for the C compiler.
-Example: scons cflags="-O3 -ffast-math"
-- cxxflags: flags for the C++ compiler.
-Example: scons cxxflags="-O3 -ffast-math"
-- ldflags: flags for the linker:
-Example: scons ldflags="-L/foo -L/bar"
-- cc: the C compiler to use:
-Example: scons cc=gcc-4.0
-- cxx: the C++ compiler to use:
-Example: scons cxx=g++-4.0
-- high-precision-as-double: set to 'y' to make sure that the
-  high-precision arithmetics performed by the Time class on
-  behalf of the user will use doubles. By default, the code
-  uses 128 integers.
-Example: scons high-precision-as-double=y
-- inheritenv: set to 'y' if you want to make your compiler
-  execute within the same environment (env vars) as your own
-  shell. This is typically used to make colorgcc work.
-Example: scons inheritenv=y
-
-2) Targets
-----------
-
-- doc: build the doxygen documentation.
-Example: scons doc
-
-- dbg-shared: a debug build using shared libraries.
-  The files are built in 'build-dir/dbg-shared/'.
-Example: scons dbg-shared
-
-- dbg-static: a debug build using static libraries
-  The files are built in 'build-dir/dbg-static/'.
-Example: scons dbg-static
-
-- opt-shared: an optimized build using shared libraries.
-  The files are built in 'build-dir/opt-shared/'.
-Example: scons opt-shared
-
-- opt-static: an optimized build using static libraries.
-  The files are built in 'build-dir/opt-static/'.
-Example: scons opt-static
-
-- dbg: an alias for dbg-shared
-Example: scons dbg
-
-- opt: an alias for opt-shared
-Example: scons opt
-
-- all: alias for dbg-shared, dbg-static, opt-shared 
-  and opt-static
-Example: scons all
-
-- gcov: code coverage analysis. Build a debugging version of
-  the code for code coverage analysis in 'build-dir/gcov'. Once
-  the code has been built, you can run various applications to
-  exercise the code paths. To generate an html report from
-  the gcov data, use the lcov-report target
-
-- lcov-report: generate html report of gcov data. The output
-  is stored in 'build-dir/lcov-report/'.
-
-- dist: generate a release tarball and zipfile from the 
-  source tree. The tarball and zipfile name are generated
-  according to the version number stored in the SConstruct
-  file.
-Example in SConstruct:
-ns3 = Ns3 ()
-ns3.name = 'foo'
-ns3.version = '0.0.10'
-Example command: scons dist
-Example output files:
-foo-0.0.10.tar.gz
-foo-0.0.10.zip
-
-- distcheck: generate a release tarball and zipfile and 
-  attempt to run the 'all' target for the release tarball.
-Example: scons distcheck
-
-3) How the build system works
------------------------------
-
-The current build system defines what are called "ns3 modules": each module
-is a set of source files, normal header files and installable header
-files. Each module also depends on a set of other modules. We build
-modules automatically in the correct order. That is, we always start
-from the module which does not depend on any other module (core) and
-proceed with the other modules and make sure that when a module is
-built, all the modules it depends upon have already been built.
-
-To build a module, we:
-1) generate the .o files
-2) link the .o files together 
-3) install the installable headers in the common directory
-top_build_dir/include/ns3.
-
-This means that if you want to use a header from your own module, you
-should just include it: #include "foo.h" but if you want to include a
-header from another module, you need to include it with #include
-"ns3/bar.h". This allows you to make sure that our "public" ns3 headers
-do not conflict with existing system-level headers.   For instance,
-if you were to define a header called queue.h, you would include
-ns3/queue.h rather than queue.h, when including from a separate module,
-since many systems provide a queue.h system include file.  
-
-4) How to add files to a module ?
----------------------------------
-
-In the main SConstruct file, you can add source code
-to the add_sources method. For example, to add a foo.cc
-file to the core module, we coud do this:
-core.add_sources ('foo.cc')
-Of course, if this file implements public API, its 
-header should be installable:
-core.add_inst_headers ('foo.h')
-
-5) How to create a new module ?
--------------------------------
-
-# create a new module. First arg is the name of
-# the new module. Second arg is the directory in
-# which all source files for this module reside.
-my_module = build.Ns3Module ('my', 'src/my_dir')
-# add it to build system
-ns3.add (my_module)
-# specify module dependencies. Here, depends
-# on the 'ipv4' and 'core' modules
-my_module.add_deps (['core', 'ipv4']) 
-# add source code to build located in 
-# src/my_dir
-my_module.add_sources ([
-	'my_a.cc',
-	'my_b.cc',
-	'my_c.cc'
-])
-my_module.add_sources ([
-	'my_d.cc'
-])
-# add headers which are not public
-my_module.add_headers ([
-	'my_a.h',
-	'my_c.h'
-])
-# add headers which are public
-my_module.add_inst_headers ([
-	'my_b.h'
-])
-my_module.add_inst_headers ([
-	'my_d.h'
-])
-# if you need to link against an external library,
-# you must add 'external' dependencies. Here, the 
-# pthread library
-my_module.add_external_dep ('pthread')
-# by default, a module is conceptually a library. If you
-# want to generate an executable from a module you need to:
-my_module.set_executable ()
-

--- a/BUILD.WAF	Thu May 17 07:51:22 2007 +0200
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,86 +0,0 @@
-WAF is an alternative build system, similar to SCons.  NS-3 now is
-able to build with WAF, in parallel to SCons.
-
-Note: the WAF build scripts are experimental at this stage.
-
-
-=== Building with WAF ===
-
-To build NS-3 with waf type the commands:
- 1. ./waf configure [options]
- 2. ./waf
-
-[ Note: if ./waf does not exist, see the section "Note for developers" below ]
-
-To see valid configure options, type ./waf --help.  The most important
-option is -d <debug level>.  Valid debug levels (which are listed in
-./waf --help) are: ultradebug, debug, release, and optimized.
-
-The resulting binaries are placed in build/<debuglevel>/srcpath.
-
-Other waf usages include:
-
- 1. ./waf check
-    Runs the unit tests
-
- 2. ./waf --doxygen
-    Run doxygen to generate documentation
-
- 3. ./waf --lcov-report
-    Run code coverage analysis (assuming the project was configured
-with --enable-gcov)
-
-=== Extending NS-3 ===
-
-To add new modules:
-  1. Create the module directory under src (or src/devices, or whatever);
-  2. Add the source files to it;
-  3. Add a 'wscript' describing it;
-  4. Add the module subdirectory name to the all_modules list in src/wscript.
-
-A module's wscript file is basically a regular WAF script.  A NS-3
-module is created as a cpp/shlib object, like this:
-
-def build(bld):
-    obj = bld.create_obj('cpp', 'shlib')
-
-    ## set module name; by convention it starts with ns3-
-    obj.name = 'ns3-mymodule'
-    obj.target = obj.name 
-
-    ## list dependencies to other modules
-    obj.uselib_local = ['ns3-core'] 
-
-    ## list source files (private or public header files excluded)
-    obj.source = [
-        'mymodule.cc',
-    ]
-
-    ## list module public header files
-    headers = bld.create_obj('ns3header')
-    headers.source = [
-        'mymodule-header.h',
-    ]
-
-
-=== Note for developers ===
-
-The NS-3 code repository does not contain the waf script.  Instead,
-developers should check it out from a subversion repository:
-
-  svn checkout http://waf.googlecode.com/svn/tags/ns3/ waf
-
-[ note: 'tags/ns3' is a tag that represents the last svn version
-tested to work correctly with ns3, although 'trunk' will likely work
- as well ]
-
-Then it can be installed system-wide with 'sudo ./waf-light install'.
-When preparing a distribution, the resulting 'waf' script, which is
-self contained (no external files needed), can be easily included in
-the tarball so that users downloading NS-3 can easily build it without
-having WAF installed (although Python >= 2.3 is still needed).
-
-The command 'waf dist' can be used to create a distribution tarball.
-It includes all files in the source directory, except some particular
-extensions that are blacklisted, such as back files (ending in ~).
-

--- a/README	Thu May 17 07:51:22 2007 +0200
+++ b/README	Thu May 17 11:32:22 2007 +0200
@@ -1,32 +1,129 @@
-ns-3 uses the Mercurial software revision control system
+
+    The Network Simulator Version 3
+    -------------------------------
+
+Table of Content:
+-----------------
+
+1) An Open Source project
+2) An overview of the ns-3 project
+3) Building ns-3
+4) Running ns-3
+5) Working with the development version of ns-3
+
 
-Mercurial cheat sheet
+1) An Open Source project
+-------------------------
+
+ns-3 is an Open Source project and we intend to make this
+project a successful collaborative project: we hope that 
+the missing pieces of the models we have not yet implemented
+will be contributed by the community in an open collaboration
+process.
+
+Contributing to the ns-3 project is still a very informal
+process because that process depends heavily on the personality
+of the people involved, the amount of time they can invest
+and the type of model they want to work on.
+
+Despite this lack of a formal process, there are a number of 
+steps which naturally stem from the open-source roots of the
+project. These steps are described in doc/contributing.txt
 
-clone this repository:
-----------------------
-hg clone http://code.nsnam.org/ns-3-dev
+2) An overview of the ns-3 project
+----------------------------------
+
+This package contains the latest version of ns-3 which is aims 
+at being a replacement for ns-2. Currently, ns-3 provides a 
+number of very simple network simulation models:
+  - an ipv4 and udp stack
+  - arp support at the bottom of the stack
+  - point-to-point physical-layer links
+  - OnOff traffic generator
 
-pull development tree changes to your local repository:
-------------------------------------------------------
-hg pull http://code.nsnam.org/ns-3-dev
-hg update (apply the changes)  OR
-hg merge (if you've made local changes)
+However, the framework is there to make adding new models as 
+simple as possible:
+  - an extensive tracing system can be used to connect
+    any number of arbitrary trace sources to any number
+    of trace sinks. This tracing system is decoupled
+    from the act of serializing the trace events to a 
+    file: users can and should provide their own
+    trace handling routines.
+
+  - simple file trace serialization support is included
+    to both text and pcap files.
+
+  - adding new MAC-level models simply requires subclassing
+    the pair of classes NetDevice and Channel.
+
+  - adding new traffic generation algorithms is also very 
+    simple through the Application and the Socket classes.
+
+3) Building ns-3
+----------------
 
-commit locally:
---------------
-hg status
-hg add <new files, if any>
-hg ci -m "message"
+The code for the framework and the default models provided
+by ns-3 is built as a set of libraries. User simulations
+are expected to be written as simple programs which make
+use of these ns-3 libraries.
+
+To build the set of default libraries and the example
+programs included in this package, you need to use the
+tool 'scons'. Detailed information on how to install
+and use scons is included in the file doc/build.txt
+
+However, the real quick and dirty way to get started is to
+type the command "scons" the the directory which contains
+this README file. The files built will be copied in the
+build-dir/dbg-shared/bin and build-dir/dbg-shared/lib
+directories. build-dir/dbg-shared/bin will contain
+one binary for each of the sample code in the 'samples'
+directory and one binary for each of the detailed examples
+found in the 'examples' directory.
+
+The current codebase is expected to build and run on the
+following set of platforms:
+  - linux x86 gcc 4.1, gcc 3.4.
+  - MacOS X ppc and x86
+
+The current codebase is expected to fail to build on
+the following platforms:
+  - gcc 3.3 and earlier
+  - optimized builds on linux x86 gcc 4.0 
+
+Other platforms might or might not work: we welcome 
+patches to improve the portability of the code to these
+other platforms.
 
-push upwards (developers access only):
---------------------------------------
-hg push ssh://code@code.nsnam.org//home/code/repos/ns-3-dev
+4) Running ns-3
+---------------
+
+On Recent Linux systems, once you have built ns-3, it 
+should be easy to run the sample programs with the
+following command:
+
+./build-dir/dbg-shared/bin/simple-p2p
+
+or:
+
+cd build-dir/dbg-shared/bin
+./simple-p2p
 
-view the change log:
---------------
-hg log <file>
+That program should generate a simple-p2p.tr text 
+trace file and a set of simple-p2p-xx-xx.pcap binary
+pcap trace files.
+
+5) Working with the development version of ns-3
+-----------------------------------------------
 
-doing a scons make clean:
-------------------------
-scons -c
+If you want to download and use the development version 
+of ns-3, you need to use the tool 'mercurial'. A quick and
+dirty cheat sheet is included in doc/mercurial.txt but
+reading through the mercurial tutorials included on the
+mercurial website is usually a good idea if you are not
+familiar with it.
 
+If you have successfully installed mercurial, you can get
+a copy of the development version with the following
+command:
+"hg clone http://code.nsnam.org/ns-3-dev"
\ No newline at end of file

--- a/RELEASE_NOTES	Thu May 17 07:51:22 2007 +0200
+++ b/RELEASE_NOTES	Thu May 17 11:32:22 2007 +0200
@@ -3,6 +3,18 @@
 
 This file contains ns-3  release notes (most recent releases first).
 
+Release 0.2 (2007/05/XX)
+========================
+
+  - Implement a new memory management infrastructure based
+    on reference counting and smart pointers (the latter being
+    optional)
+
+  - Implement a COM-like framework with support for QueryInterface
+    to provide object extensibility
+
+  - Add support for a BSD-style socket API for user applications
+
 Release 0.1 (2007/03/31)
 ========================
 

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/build-waf.txt	Thu May 17 11:32:22 2007 +0200
@@ -0,0 +1,86 @@
+WAF is an alternative build system, similar to SCons.  NS-3 now is
+able to build with WAF, in parallel to SCons.
+
+Note: the WAF build scripts are experimental at this stage.
+
+
+=== Building with WAF ===
+
+To build NS-3 with waf type the commands:
+ 1. ./waf configure [options]
+ 2. ./waf
+
+[ Note: if ./waf does not exist, see the section "Note for developers" below ]
+
+To see valid configure options, type ./waf --help.  The most important
+option is -d <debug level>.  Valid debug levels (which are listed in
+./waf --help) are: ultradebug, debug, release, and optimized.
+
+The resulting binaries are placed in build/<debuglevel>/srcpath.
+
+Other waf usages include:
+
+ 1. ./waf check
+    Runs the unit tests
+
+ 2. ./waf --doxygen
+    Run doxygen to generate documentation
+
+ 3. ./waf --lcov-report
+    Run code coverage analysis (assuming the project was configured
+with --enable-gcov)
+
+=== Extending NS-3 ===
+
+To add new modules:
+  1. Create the module directory under src (or src/devices, or whatever);
+  2. Add the source files to it;
+  3. Add a 'wscript' describing it;
+  4. Add the module subdirectory name to the all_modules list in src/wscript.
+
+A module's wscript file is basically a regular WAF script.  A NS-3
+module is created as a cpp/shlib object, like this:
+
+def build(bld):
+    obj = bld.create_obj('cpp', 'shlib')
+
+    ## set module name; by convention it starts with ns3-
+    obj.name = 'ns3-mymodule'
+    obj.target = obj.name 
+
+    ## list dependencies to other modules
+    obj.uselib_local = ['ns3-core'] 
+
+    ## list source files (private or public header files excluded)
+    obj.source = [
+        'mymodule.cc',
+    ]
+
+    ## list module public header files
+    headers = bld.create_obj('ns3header')
+    headers.source = [
+        'mymodule-header.h',
+    ]
+
+
+=== Note for developers ===
+
+The NS-3 code repository does not contain the waf script.  Instead,
+developers should check it out from a subversion repository:
+
+  svn checkout http://waf.googlecode.com/svn/tags/ns3/ waf
+
+[ note: 'tags/ns3' is a tag that represents the last svn version
+tested to work correctly with ns3, although 'trunk' will likely work
+ as well ]
+
+Then it can be installed system-wide with 'sudo ./waf-light install'.
+When preparing a distribution, the resulting 'waf' script, which is
+self contained (no external files needed), can be easily included in
+the tarball so that users downloading NS-3 can easily build it without
+having WAF installed (although Python >= 2.3 is still needed).
+
+The command 'waf dist' can be used to create a distribution tarball.
+It includes all files in the source directory, except some particular
+extensions that are blacklisted, such as back files (ending in ~).
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/build.txt	Thu May 17 11:32:22 2007 +0200
@@ -0,0 +1,182 @@
+If you want to build ns3, you need to install scons (see
+http://www.scons.org). scons takes care of building
+the whole source tree using your system compiler. scons
+0.91.1 and 0.91.96 have been tested and are known to 
+work on linux FC5, Mac os X and MinGW.
+
+To start a build, you can just type 'scons' which
+will generate a debug shared build by default, located
+in the directory 'build-dir/dbg-shared/bin' and
+'build-dir/dbg-shared/lib'.
+
+All builds are built with debugging symbols. Debugging
+builds enable asserts while optimized builds disable them.
+On platforms which support it, rpath is used which means that
+the executable binaries generated link explicitely against
+the right libraries. This saves you the pain of having to
+setup environment variables to point to the right libraries.
+
+1) Options
+----------
+
+- verbose: if you have installed scons 0.91.96 or higher, 
+  the default build output is terse. To get a more verbose 
+  output, you need to set the 'verbose' variable to 'y'.
+Example: scons verbose=y
+- cflags: flags for the C compiler.
+Example: scons cflags="-O3 -ffast-math"
+- cxxflags: flags for the C++ compiler.
+Example: scons cxxflags="-O3 -ffast-math"
+- ldflags: flags for the linker:
+Example: scons ldflags="-L/foo -L/bar"
+- cc: the C compiler to use:
+Example: scons cc=gcc-4.0
+- cxx: the C++ compiler to use:
+Example: scons cxx=g++-4.0
+- high-precision-as-double: set to 'y' to make sure that the
+  high-precision arithmetics performed by the Time class on
+  behalf of the user will use doubles. By default, the code
+  uses 128 integers.
+Example: scons high-precision-as-double=y
+- inheritenv: set to 'y' if you want to make your compiler
+  execute within the same environment (env vars) as your own
+  shell. This is typically used to make colorgcc work.
+Example: scons inheritenv=y
+
+2) Targets
+----------
+
+- doc: build the doxygen documentation.
+Example: scons doc
+
+- dbg-shared: a debug build using shared libraries.
+  The files are built in 'build-dir/dbg-shared/'.
+Example: scons dbg-shared
+
+- dbg-static: a debug build using static libraries
+  The files are built in 'build-dir/dbg-static/'.
+Example: scons dbg-static
+
+- opt-shared: an optimized build using shared libraries.
+  The files are built in 'build-dir/opt-shared/'.
+Example: scons opt-shared
+
+- opt-static: an optimized build using static libraries.
+  The files are built in 'build-dir/opt-static/'.
+Example: scons opt-static
+
+- dbg: an alias for dbg-shared
+Example: scons dbg
+
+- opt: an alias for opt-shared
+Example: scons opt
+
+- all: alias for dbg-shared, dbg-static, opt-shared 
+  and opt-static
+Example: scons all
+
+- gcov: code coverage analysis. Build a debugging version of
+  the code for code coverage analysis in 'build-dir/gcov'. Once
+  the code has been built, you can run various applications to
+  exercise the code paths. To generate an html report from
+  the gcov data, use the lcov-report target
+
+- lcov-report: generate html report of gcov data. The output
+  is stored in 'build-dir/lcov-report/'.
+
+- dist: generate a release tarball and zipfile from the 
+  source tree. The tarball and zipfile name are generated
+  according to the version number stored in the SConstruct
+  file.
+Example in SConstruct:
+ns3 = Ns3 ()
+ns3.name = 'foo'
+ns3.version = '0.0.10'
+Example command: scons dist
+Example output files:
+foo-0.0.10.tar.gz
+foo-0.0.10.zip
+
+- distcheck: generate a release tarball and zipfile and 
+  attempt to run the 'all' target for the release tarball.
+Example: scons distcheck
+
+3) How the build system works
+-----------------------------
+
+The current build system defines what are called "ns3 modules": each module
+is a set of source files, normal header files and installable header
+files. Each module also depends on a set of other modules. We build
+modules automatically in the correct order. That is, we always start
+from the module which does not depend on any other module (core) and
+proceed with the other modules and make sure that when a module is
+built, all the modules it depends upon have already been built.
+
+To build a module, we:
+1) generate the .o files
+2) link the .o files together 
+3) install the installable headers in the common directory
+top_build_dir/include/ns3.
+
+This means that if you want to use a header from your own module, you
+should just include it: #include "foo.h" but if you want to include a
+header from another module, you need to include it with #include
+"ns3/bar.h". This allows you to make sure that our "public" ns3 headers
+do not conflict with existing system-level headers.   For instance,
+if you were to define a header called queue.h, you would include
+ns3/queue.h rather than queue.h, when including from a separate module,
+since many systems provide a queue.h system include file.  
+
+4) How to add files to a module ?
+---------------------------------
+
+In the main SConstruct file, you can add source code
+to the add_sources method. For example, to add a foo.cc
+file to the core module, we coud do this:
+core.add_sources ('foo.cc')
+Of course, if this file implements public API, its 
+header should be installable:
+core.add_inst_headers ('foo.h')
+
+5) How to create a new module ?
+-------------------------------
+
+# create a new module. First arg is the name of
+# the new module. Second arg is the directory in
+# which all source files for this module reside.
+my_module = build.Ns3Module ('my', 'src/my_dir')
+# add it to build system
+ns3.add (my_module)
+# specify module dependencies. Here, depends
+# on the 'ipv4' and 'core' modules
+my_module.add_deps (['core', 'ipv4']) 
+# add source code to build located in 
+# src/my_dir
+my_module.add_sources ([
+	'my_a.cc',
+	'my_b.cc',
+	'my_c.cc'
+])
+my_module.add_sources ([
+	'my_d.cc'
+])
+# add headers which are not public
+my_module.add_headers ([
+	'my_a.h',
+	'my_c.h'
+])
+# add headers which are public
+my_module.add_inst_headers ([
+	'my_b.h'
+])
+my_module.add_inst_headers ([
+	'my_d.h'
+])
+# if you need to link against an external library,
+# you must add 'external' dependencies. Here, the 
+# pthread library
+my_module.add_external_dep ('pthread')
+# by default, a module is conceptually a library. If you
+# want to generate an executable from a module you need to:
+my_module.set_executable ()
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/contributing.txt	Thu May 17 11:32:22 2007 +0200
@@ -0,0 +1,53 @@
+
+Contributing to the ns-3 project
+--------------------------------
+
+Despite the lack of a formal contribution process to the ns-3
+project, there are a number of steps which we expect every
+potential contributor to follow. These naturally stem from 
+the open-source roots of the project:
+
+  - first, you should subscribe to the ns-developers 
+    mailing-list (see http://www.nsnam.org/mailing_lists.html)
+
+  - then, you should send an email there stating your interest
+    in working on a specific part of the models and trying
+    to explain how you would like to implement it, what 
+    resources you have, etc.
+
+  - you should be prepared to work together with the other
+    potential contributors who want to work on the same models.
+
+  - you should be prepared to go through code reviews with the
+    ns-3 development team prior to integration. The goal of these
+    code reviews is to:
+      - ensure adherence to the coding style of the project
+        (see doc/codingstyle.html)
+      - ensure that the structure of your code has a certain 
+        coherence with regard to the rest of the ns-3 codebase
+      - improve the quality of the code: we strongly believe in
+        the old saying: "many eyes make all bugs shallow".
+      - increase code reuse by trying to generalize certain 
+        useful pieces of your code to make them available to
+        other models.
+
+  - you should be prepared to try to integrate as many tests
+    in the codebase as possible: we understand that writing
+    tests is not sexy and that not everyone is convinced that
+    they improve the code-writing poductivity which is why
+    we do not enforce strict rules about testing. However,
+    we expect model authors to answer basic questions about
+    how they plan to test and validate their models.
+
+  - you should be prepared to maintain your model once it is
+    integrated: while we consider every bug filed against the 
+    simulator as being a bug we must deal with and while we 
+    will try to fix as many bugs as humanly possible, we
+    also expect model authors to act as responsible maintainers
+    and be reactive to bug reports concerning their models.
+
+  - you should make sure that you understand that contributed
+    models should be licensed under the GPLv2. You do not have
+    to assign your copyright to the ns-3 project but you must
+    accept the terms of the GPLv2. See the following link:
+    http://www.fsf.org/licensing/licenses/info/GPLv2.html

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/mercurial.txt	Thu May 17 11:32:22 2007 +0200
@@ -0,0 +1,44 @@
+Introduction
+------------
+
+ns-3 uses the Mercurial software revision control system which
+is a replacement for tools liks cvs or subversion. Thus, to get
+access to the developement versions of ns-3, you need to install
+mercurial first. See http://www.selenic.com/mercurial/wiki/
+
+Mercurial cheat sheet
+---------------------
+
+Look at our project history and source code:
+-------------------------------------------
+http://code.nsnam.org/ns-3-dev
+
+clone this repository:
+---------------------
+hg clone http://code.nsnam.org/ns-3-dev
+
+commit locally:
+--------------
+hg status
+hg add <new files, if any>
+hg ci -m "message"
+
+pull development tree changes to your local repository:
+------------------------------------------------------
+hg ci -m "my local changes are recorded"
+hg pull http://code.nsnam.org/ns-3-dev
+hg update (apply the changes)  OR
+hg merge (if you've made local changes)
+
+view the change log:
+-------------------
+hg log <file>
+
+push upwards (developers access only):
+--------------------------------------
+To the main repository:
+hg push ssh://code@code.nsnam.org/repos/ns-3-dev
+To your private repository:
+hg push ssh://username@code.nsnam.org//home/username/repositories/username/repository
+
+