[Ns-developers] ns-3.4 : The Bug List

[Raj Bhattacharjea]

On Thu, Feb 26, 2009 at 3:20 PM, Tom Henderson <tomh at tomh.org> wrote:
>
>>-----Original Message-----
>>From: Raj Bhattacharjea [mailto:raj.b at gatech.edu]
>>Sent: Thursday, February 26, 2009 11:32 AM
>>To: 'ns-developers'
>>Subject: [Ns-developers] ns-3.4 : The Bug List
>>
>>We have wrapped up the open phase on ns-3.4, where we were merging
>>trees and new features.  We successfully merged the RandomVariable API
>>changes, the Object Naming Service, and the TapNetDevice changes.
>>Looking forward, we have some bugs to squash before we ship the first
>>release candidiate for ns-3.4.
>
> Raj,
>
> I think that you should separate "blockers for issuing the first release candidate" from "blockers for releasing ns-3.4".  We've already agreed that some of those bugs (e.g., documentation) are not things that need to hold up release candidate testing.  103 seems to be of the enhancement variety.

The policy I was hoping to adopt is to NOT make this distinction.  If
there is something that needs to not hold up release candidate testing
which is currently marked P1, lets discuss it and then mark it P2 so
it is in the category of "not holding up the release".

>
> The list needs freshened, also.  Can you please apply, for instance, the patches 468 and 490 (490 will require new traces for a couple of tests)?  Also, there is no "Status:" for any of the bugs you listed.
>

The patches you mention will be applied.  The status field needs to be
clarified; I was hoping that the maintainers could each add what the
present status of the bug is, and when they plan on having a fix.  Did
you mean anything else by refreshing?

> We discussed that ideally it would be nice to issue a RC with no known blockers, but if we hold to that criteria, what is your estimated date for the first RC?  What is the estimate for the first RC if we instead have a policy of not waiting for all P1 bugs to be resolved (which ones would you wait for in that case)?

I'd like to reiterate, I would really like to adopt the policy that an
RC will not be released with broken behavior; in my opinion, this
means fixing the P1 bugs in the tracker; these need to be adjusted
however to arrive at a list which we can agree on.  Once the consensus
is arrived at, and maintainers give be estimated "done by" dates, I
will be able to give an estimate of when the RC will be posted.
Without more feedback, it is difficult to commit to a date, given that
we wait for P1 bugs to be fixed.  I have the hope that the date will
converge upon something like March 16 for RC1, but this is what I am
pushing for.


-- 
Raj Bhattacharjea
Georgia Institute of Technology
School of Electrical and Computer Engineering
Ph.D. Candidate
Systems Analyst
404.894.2955