CCNx Community

We invite you to connect with Project CCNx whether you are just curious or want to get involved!

Mailing Lists

Subscribe to the CCNx Mailing Lists for up to date information, as well as access to our development community.

Developing an application for use with CCNx? Diving into the code? Use this mailing list to keep in touch with us and others within the development community.

Installation, testing, and use questions.

CCNx related announcements from the core development team. This low traffic list will keep you in touch with the current progress of the project.

Twitter @projectccnx

One way to support the CCNx project is to help spread the word.  Have something interesting to say about CCNx?  Having problems with the latest build?  Want to tell people about something interesting you are doing with CCNx?  Tweet it.  When doing so, use the #ccnx hash tag with your tweets.  This helps contextual search and increases the visibility of your posts.

Come across an interesting tweet about Project CCNx?  Re-tweet it.

Bugs or Feature Requests

Like good documentation, code quality is an essential ingredient for success. The Core team is dedicated to making sure high priority bugs are fixed, and we need your help to get an accurate account of outstanding issues.  We also welcome feature requests filed in the same tracking system.

If you run across an issue with the software release or documentation, or this site, do the following:

Check with the ccnx-users mailing list to see if other people have experienced a similar problem.  Sometimes the issue is related to configuration or involves messages or symptoms that are hard to interpret.  A quick check with the community can help get you past such problems faster, or at least help you to figure out whether the issue is with documentation, diagnostics, or real implementation bugs.

Don’t be shy about filing issues in the project Bugtracker (regardless of which kind they are)!  We do ask that you  perform a quick search of the database first, to see if the issue has already been filed.  This can be tricky, and we recognize that the same bug can manifest in different ways or may be described differently by different people.  When in doubt, go ahead and file the bug.

Your help with a bug can range from reporting, to evaluation, to suggesting a workaround or fix, to creating a fix.

CCNx is using a Redmine Issue Tracker to keep track of bugs and feature requests.

Anyone may read or search the bug database without logging in, but in order add new issues you’ll need to have a Redmine account.  If you do not have one, go ahead and create a new Redmine account but please use the same user name that you use on rest of the site (if you have one).  We apologize for the inconvenience caused by the fact that Redmine has a separate account database.

As a general primer on bug filing, and to provide information vital to diagnosing the problem, we suggest you read the Bug Filing Guidelines.

Once filed, you will receive an email about your new bug.  You will continue to receive bug status changes through the life of the bug.

If you have found the bug to exist already, that’s ok. There is still a chance for you to provide some seriously helpful feedback on the bug state.  Frequently, bugs will get closed by Core developers because they are duplicate, marked as won’t fix, works for me, or need-more-info.  Frustrating as this can be to users and developers, bugs must go through a triage.  If you feel there is something you can add to the dialogue around a specific bug, please chime in.  Add a description of your specific issues.  Chiming in with a “me too” is fine, but even more useful is to add something to the discussion.  “Why was this bug closed as fixed when I can still reproduce it?”  “When will this get assigned and fixed?”  etc.

Has your bug been fixed?  Are you getting proper feedback from the Core dev team.  If you feel you aren’t being heard, feel free to take the discussion onto the mailing list to escalate.  Frequently bugs are fixed to support specific release goals, and so bugs existing outside of core project goals may see deprioritization.

If you have not already, please review the prerequisite steps in the previous Issue Tracking section 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.

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
  • 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.


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.

Wiki and Documentation

One of the most important aspects reflecting the quality of an open source project is the availability of high quality documentation.  There are two broad classes of documentation:

  • Online notes: Contribute to the Wiki on this web site.
  • Documentation in the distribution: Contribute as a code contribution which is detailed in the section below.

Contribute to the Code

We encourage contributions to the source code (including documentation in the code tree), here’s how to get setup:

In order to make contributions you must first sign and return the  to assure that contributed code may be redistributed consistent with the open source licenses used in Project CCNx.  You must also join the ccnx-dev mailing list and become and active member.

Project CCNx uses git for managing the source code, so get your git repo set up.

Get involved in the technical discussion as appropriate and initiate discussion about new work before investing a lot of effort.

Update the bug database with information related to what they are working on or have discovered.

You may volunteer to work on a bug by writing to ccnx-dev mentioning the bug id.  After discussion and confirmation the project managers may assign the bug to you.

Submit patches created with git format-patch for consideration by the Core Development team. (This process is still to be refined and documented, it may change)