Difference between revisions of "Ns-3.3"

From Nsnam
Jump to: navigation, search
Line 5: Line 5:
 
== The Release Manager ==
 
== The Release Manager ==
  
−
Craig Dowell (craigo at ee.washington.edu) is the release manager for ns-3.3 and is the contact for any release issues.
+
Craig Dowell (craigdo at ee.washington.edu) is the release manager for ns-3.3 and is the contact for any release issues.
  
 
ns-3.3 is scheduled for release in December 15, 2008.   
 
ns-3.3 is scheduled for release in December 15, 2008.   
Line 32: Line 32:
 
# December 15 -- ns-3.4 Open period begins.
 
# December 15 -- ns-3.4 Open period begins.
  
−
As described in [[Roadmap]]
+
As described in the [[Roadmap]] there are three broad sections in the release schedule.  During the open phase, people wanting to include a new feature in ns-3.3 should contact craigdo and arrange to have their features merged into ns-3-dev.  You will be expected to provide the following:
  
 +
# A mercurial patch or bundle against the current version of ns-3-dev that contains your proposed feature addition.  You need to make sure that I can apply this patch and build and run (debug and optimized as appropriate) all unit and regression tests sucessfully on all of our target machines;
 +
# A summary of the additions you are proposing and an explanation of any changes to existing code that had to be done in order to support your feature (this will be used to genenerate release notes and will be provided to maintainers if a code review is indicated);
 +
# Some kind of unit or regression test that I can use to determine if your feature is actually working at each stage of the integration.
  
−
In "Open" phase, the release manager has a low profile.  However, the release
+
I will take a quick look at your proposed addition and determine if a code review is required.  According to the ''book of instructions'' a code review requiring positive acknowledgement by maintainers is indicated if:
−
manager should be involved with scheduling and approving major merges,
+
−
because he or she may want to manage the dependencies and do some testing
+
−
in a particular order.  In open phase, modules that are self contained
+
−
(e.g. a new channel model for WiFi) don't really need much coordination
+
−
with the release manager.
+
  
−
(See below for "major merges").
+
# Your proposed feature does not work with all models or on all platforms;
 +
# Your feature changes pre-existing APIs;
 +
# Your feature crosses maintainer boundaries.
  
−
In "Maintenance" phase, no new features are to be added, but the maintainers
+
Just to be safe, I will probably run a feature submission by at least one maintainer according to the general area of applicability of the feature.  For example, if you submit an entirely new device driver model, as a courtesy I will run this submission by the maintainers of the current devices.  The maintainers won't have any responsibility to positively ack the submission, but I will take some time to allow a reasonable review.
−
may check in fixes to bugs.  Maintainers may appeal to the release manager
+
−
for adding new self-contained features, but it is release manager's call.
+
  
−
In Code freeze phase, the release manager must approve (or apply) all changes
+
I will coordinate new feature merges beginning at the start of the open phase (September 22, 2008).  The absolute final deadline for feature inclusion in ns-3.3 is the start of the "Late merge period." This is the time during which I merge the code from all of those people who have waited until the last minute and work out any system integration issues that pop up.  If you miss the start of the late merge period, or have a feature that is not design-reviewed by the start of the late merge period, well, sorry.  You get to wait until the ns-3.4 open period to try again.
−
to ns-3-dev outside of documentation.  The release manager may also set
+
−
a freeze date on documentation.
+
  
−
Typically, the feature freeze is 4-6 weeks before the projected release
+
The end of the late merge period coincides with the beginning of the maintenance phase.  No new features may be added, but the maintainers may check in fixes to bugs; and people with new features that have been accepted and merged may fix bugs in existing features.  Please don't try to sneak in more new features or you may have your whole feature set removed at the release manager's discretion.  You can ask me if you want to add small, self-contained features, but there are no guarantees that I will okay them.
−
date, and the code freeze is 2 weeks before the projected release date.
+
  
−
The release manager is responsible for preparing and maintaining RELEASE_NOTES,
+
On December 1st, we are going to enter the code freeze phase. This indicates that we are in the final stages of the release and our primary goal is stability. During the code freeze phase, only P1 bugfixes will be allowed to be checked in.  I will begin my daily annoying emails listing all of the priority one bugs that are outstanding.  Our ''goal'' will be to reduce the number of P1 bugs to zero before the release of ns-3.3.
−
changes.html, and release candidates, and for updating web pages and
+
−
wikis concerning release-specific information (e.g., update the Installation
+
−
wiki page if there is an issue discovered with a compiler).
+
  
−
Detailed steps for doing the source code release are found in the [http://code.nsnam.org/ns-3-dev/file/1e8249c58fda/doc/release_steps.txt doc/release_steps.txt] file in the ns-3-dev repository.
+
'''''I reserve the right to veto (and remove) any new feature addition if it begins to cause problems and looks like it threatens the stability of the release at any time in the release process'''''
  
−
=== Major merges ===  
+
== Candidates for Merge into ns-3.3 ==
  
−
Major merges are those that are not self contained within the scope of a
+
As you can see in the [[Roadmap]], we have identified several candidates for inclusion in ns-3.3.  As time passes, I will add more status regarding the progress of these new features.
−
single maintainer, those that change API, and those that have some issues
+
−
with the build system or other dependencies.
+
  
−
Past examples of major merges:
+
# build system refactoring
−
* NSC
+
# IPv4/routing refactoring
−
* Bridge device and promiscuous mode
+
# Basic IPv6 Support
−
* Attribute system
+
# Emulation Mode Support
−
* Python bindings
+
  
−
If a proposed new feature (or refactoring) meets one of these criteria:
+
[[User:Craigdo|Craigdo]] 17:53, 7 October 2008 (EDT)
−
# Does not work with all models or on all platforms
+
−
# Changes existing APIs
+
−
# Crosses maintainer boundaries
+
−
 
+
−
then, the release manager will ask for code review by all maintainers and
+
−
request a positive ack that the maintainer is comfortable with the
+
−
proposed merge and believes that it will interact well with, or have
+
−
no effect on, his or her component.  This code review process will typically
+
−
lead to questions and comments that need resolution.
+
−
 
+
−
In the case where a new model does not work with the existing simulator,
+
−
(not on all platforms, not with all existing models) then the model
+
−
must receive an approval (exception) from the architecture board or project
+
−
lead.  Typically, they will either grant this exception or ask the model
+
−
author to improve the support and come back later.
+
−
 
+
−
The release manager can veto a major merge based on preliminary testing or
+
−
concern about looming problems to finalize things for the release.
+
−
 
+
−
Finally, it is good practice to coordinate among the active committers and release manager when you are doing a major merge, to avoid bad merge collisions.
+

Revision as of 21:53, 7 October 2008

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers

This page summarizes the release planning for ns-3.3.

The Release Manager

Craig Dowell (craigdo at ee.washington.edu) is the release manager for ns-3.3 and is the contact for any release issues.

ns-3.3 is scheduled for release in December 15, 2008.

The ns-3.3 Release Schedule

ns-3 releases are based on date-driven schedules as opposed to feature-driven schedules. We decide on a release date and then the release manager works backward to define windows during which time certain activites related to the release can happen. This has been done for ns-3.3 and the important milestones are:

  1. September 22 -- ns-3.2 posted;
  2. September 22 -- ns-3.3 Open phase begins;
  3. October 20 -- Recommended cutoff for new feature submission;
  4. October 27 -- Deadline for new feature submissions that require design review;
  5. November 3 -- Approved new feature ready-for-merge deadline;
  6. November 3 -- Late merge period begins;
  7. November 10 -- Late merge period ends;
  8. November 10 -- Open phase ends;
  9. November 10 -- Maintenance phase begins;
  10. December 1 -- Maintenance phase ends;
  11. December 1 -- Code freeze phase begins;
  12. December 1 -- ns-3.3-RC1;
  13. December 4 -- ns-3.3-RC2;
  14. December 8 -- ns-3.3-RC3;
  15. December 11 -- ns-3.3-RC4;
  16. December 15 -- ns-3.3 posted
  17. December 15 -- Code freeze phase ends;
  18. December 15 -- ns-3.4 Open period begins.

As described in the Roadmap there are three broad sections in the release schedule. During the open phase, people wanting to include a new feature in ns-3.3 should contact craigdo and arrange to have their features merged into ns-3-dev. You will be expected to provide the following:

  1. A mercurial patch or bundle against the current version of ns-3-dev that contains your proposed feature addition. You need to make sure that I can apply this patch and build and run (debug and optimized as appropriate) all unit and regression tests sucessfully on all of our target machines;
  2. A summary of the additions you are proposing and an explanation of any changes to existing code that had to be done in order to support your feature (this will be used to genenerate release notes and will be provided to maintainers if a code review is indicated);
  3. Some kind of unit or regression test that I can use to determine if your feature is actually working at each stage of the integration.

I will take a quick look at your proposed addition and determine if a code review is required. According to the book of instructions a code review requiring positive acknowledgement by maintainers is indicated if:

  1. Your proposed feature does not work with all models or on all platforms;
  2. Your feature changes pre-existing APIs;
  3. Your feature crosses maintainer boundaries.

Just to be safe, I will probably run a feature submission by at least one maintainer according to the general area of applicability of the feature. For example, if you submit an entirely new device driver model, as a courtesy I will run this submission by the maintainers of the current devices. The maintainers won't have any responsibility to positively ack the submission, but I will take some time to allow a reasonable review.

I will coordinate new feature merges beginning at the start of the open phase (September 22, 2008). The absolute final deadline for feature inclusion in ns-3.3 is the start of the "Late merge period." This is the time during which I merge the code from all of those people who have waited until the last minute and work out any system integration issues that pop up. If you miss the start of the late merge period, or have a feature that is not design-reviewed by the start of the late merge period, well, sorry. You get to wait until the ns-3.4 open period to try again.

The end of the late merge period coincides with the beginning of the maintenance phase. No new features may be added, but the maintainers may check in fixes to bugs; and people with new features that have been accepted and merged may fix bugs in existing features. Please don't try to sneak in more new features or you may have your whole feature set removed at the release manager's discretion. You can ask me if you want to add small, self-contained features, but there are no guarantees that I will okay them.

On December 1st, we are going to enter the code freeze phase. This indicates that we are in the final stages of the release and our primary goal is stability. During the code freeze phase, only P1 bugfixes will be allowed to be checked in. I will begin my daily annoying emails listing all of the priority one bugs that are outstanding. Our goal will be to reduce the number of P1 bugs to zero before the release of ns-3.3.

I reserve the right to veto (and remove) any new feature addition if it begins to cause problems and looks like it threatens the stability of the release at any time in the release process

Candidates for Merge into ns-3.3

As you can see in the Roadmap, we have identified several candidates for inclusion in ns-3.3. As time passes, I will add more status regarding the progress of these new features.

  1. build system refactoring
  2. IPv4/routing refactoring
  3. Basic IPv6 Support
  4. Emulation Mode Support

Craigdo 17:53, 7 October 2008 (EDT)

Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=Ns-3.3&oldid=1949"