Software Download Information Request

To help the CCNx project team better understand the user base of the project, we are asking you to provide a few details below. Skip this step by clicking on the "X" or outside of this box.

Your Email

Company or Organization

Home  ›  Support  ›  Bug Filing Guidelines

Bug Filing Guidelines

Getting Started

If you have not already, please walk through prerequisite steps before you reach the point of actually filing a bug.  It may sound trite, but bugs are expensive to fix in the field (i.e., after a customer/user has discovered the problem), and even harder to keep a handle on when teams are small and resources are thin.  If you are sure you have a new bug on your hands, please read onward, and sign up for a redmine account.

Elements of Bug Style

A good bug (if there is such a thing) has the following characteristics:

  • Clear and concise
  • Reproducible (if at possible) from the description
  • Big or small (we don’t care, and we don’t judge–a bug is a bug)
  • Contains fact (a clear account of what happened, backed by available data)
  • Uncluttered (keep traces and dumps in attachments, or use pastie.org).
  • Of proper priority (read below on Project Bug Priorities)

Project Bug Tracker Types

When filing please be sure to choose the right tracker.  This is a redmine thing, so choose from:

  • Bug – use for all bugs
  • Feature Request – use to request enhancements, which will be reviewed during release planning.  Someone may contact you to explain your feature further.
  • Support Request – If you need help on something, and mailing lists haven’t been of use, then consider using this.  We urge you to try other methods, as they are more likely to get fully reviewed.

CCNx Bug Priorities

The CCNx Project has modified its redmine instance to support a more rational approach to bug priorities.  Reality is that P1 bugs get developer attention, and we don’t like to ship with bugs of level P1-P3, and P4s and P5s are often left in limbo for triage on the next release.  To avoid this, we’ve simplified the bug priorities down to Low (P3) , Med (P2) , High (P1).

So when filing bugs, please review these criteria to understand how to classify your bug:

  • High (P1) – These bugs are system critical, resulting in failure of the system in a special case or in a mainstream use case.
  • Med (P2) - These bugs result in a failure of a specific feature, though not necessarily one that will cause a system wide failure.
  • Low (P3) – These bugs are non-critical bugs that may cause portions of a feature to not behave as intended.

Releases

Every developer and user will be working from either (1) a stable release, (2) a development snapshot, or (3) a private fork.  The CCNx team can most effectively deliver bug fixes when we know in what release the bug occurs.  Please specify the release or build # when filing a bug.  If left blank, we’ll need to perform forensics to find out how to even triage the bug.  Better to be specific, or select all releases.   For anyone working from a private fork (i.e., core CCNx code that you’ve modified), be aware we can’t accurately fix bugs in your code.  If a problem exists in the general stable releases or dev snapshots, we’ll review it.  If it only exists in your private fork, please produce a test case that can be run against a stable release.

CCNx Bug Categories

The following categories will be used to organize bugs by project functional area:

  • build
  • release
  • test
  • More to come…

Other Bug Fields

Every bug is unique, like a snow flake.  We are going with the simplest form of bug tracking for now, with a simple description field which leaves you with plenty of space to file all relevant information.  If you feel we are missing something essential, let us know.  Also, don’t feel the need to set any information for which you aren’t sure.  We can always categorize, assign, estimate, and triage after you’ve filed your bug.

Updating Your Bugs

If you’ve discovered some new data about your bug, please post it as a bug update.  Redmine closes edits to the default bug values once created, so you are free to add updates to clarify or correct any information not provided in the original bug.

Tracking Your Bugs

Fortunately, redmine does do a few nice things to help you track your bugs.  It will send you email notifications if you so choose to receive these emails.  It will also provide a place to track your bugs. You can also “star” any bug to watch it.  It will then be in your tracker even if you haven’t created the bug or commented on the bug.