[Ns-developers] bug priorities

[raj bhattacharjea]

On Fri, Feb 20, 2009 at 6:09 PM, Tom Henderson <tomh at tomh.org> wrote:
> Raj Bhattacharjea wrote:
>
>>
>> I expect this last round of random variables changes will be done and
>> merged by Monday.  I'll follow up then about the bugs to fix for
>> ns-3.4
>
> One thing that Raj and Craig and I discussed today was to adopt a tracker
> convention that priority P1 is equivalent to release blocker, and that P1
> would, in general, be reserved for verified broken behavior.  Under this
> policy, some of our current P1 bugs which are more in the category of
> feature enhancement would move to P2 (P2 becomes "we'll try to fix this in
> the current release cycle, but they will not block the release").
>
> The other option would be to use the severity field in the tracker to encode
> blocker.  We would then have different categories of P1 bugs, P2 bugs, etc.
>  I don't care much either way but if someone has a strong preference against
> the above proposal, please suggest it now.
>

To summarize, P1 bugs are being split into P1 and P2 bugs; the current
P2 bugs similarly get demoted to P3, and the current P3 bugs drop into
the as of yet unused category P4.  This means each of the groups has
the following priority:

P1 - Most severe bugs that block the release of ns-3.4
P2 - Features that are targets for ns-3.4 but won't block the release
P3 - Severe bugs that will block the release of ns-3.5
P4 & P5 - Bugs whose future is undecided as of yet; might get priority
in later releases, might not

At present, all of these changes have been implemented for the open
tracker bugs except for splitting the P1 bugs up.  I am going through
these now deciding what is a blocker and what is not.

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