- 1 OpenDaylight Bugs
- 2 Important Fields and How They Are Used
- 3 Open Bugs
- 3.1 Helium Blocking Bugs (all projects)
- 3.2 aaa
- 3.3 affinity
- 3.4 bgpcep
- 3.5 controller
- 3.6 defense4all
- 3.7 didm
- 3.8 dlux
- 3.9 docs
- 3.10 groupbasedpolicy
- 3.11 integration
- 3.12 l2switch
- 3.13 lispflowmapping
- 3.14 net-virt-platform
- 3.15 odlparent
- 3.16 opendove
- 3.17 openflowjava
- 3.18 openflowplugin
- 3.19 opflex
- 3.20 ovsdb
- 3.21 packetcable
- 3.22 persistence
- 3.23 plugin2oc
- 3.24 reservation
- 3.25 sdninterfaceapp
- 3.26 sfc
- 3.27 snbi
- 3.28 snmp4sdn
- 3.29 tcpmd5
- 3.30 toolkit
- 3.31 TSC
- 3.32 ttp
- 3.33 vtn
- 3.34 yangtools
The OpenDaylight Bugs can be found here: bugs.opendaylight.org.
Working on a bug
Check out the Life_Cycle_of_a_Bug wiki page.
Important Fields and How They Are Used
Each bug has a few important fields. It is helpful to understand how they are commonly used. The fields are:
- Product - The Product is the OpenDaylight project that contains the code which has the bug.
- Comp - The component attempts to identify the module within the project which contains the code which has the bug.
- Assignee - This is the person assigned to working this bug. Bugs are self-assigned, meaning if a bug is not currently assigned it is free to be worked!
- Status - This represents the status of the bug. When bugs are initial logged they generally are added in the "confirmed" state. Bugs that are actively being worked they should be placed into In Progress. Bugs that are waiting for final validation / verification should be "Waiting for Verification". Once validated the bugs are closed.
- Summary - The summary field should contain a short description of the problem encountered. Try placing some keywords here as well to help people identify problem areas.
- Description - The description is perhaps the most important field. It should contain a description of the problem and more importantly a description of how you REPRODUCE the problem. Finally if you have thoughts on how it should be / could be fixed please include those as well.
- Target Milestone - The target Milestone is generally set by the developer doing the work. See below for an example of the different Milestones that are out there and how they are generally used.
The Target Milestone field contains an entry for the current release (including all of the planned milestones, release candidates and expected post release service updates). For example some current available milestones as of Sept 9th 2014 are:
- Helium -> The release name without any modifies is an indication that the bug should be targeted to be fixed sometime during that release. If a bug reporter wants a bug fixed within a specific release they can set the target milestone to this.
- Helium-1 -> The dash # indicates that this will be the first, second etc service pack (bug fix) that is release AFTER the Helium project.
- Helium-M4 -> The M# indicates that this is targeted to be fixed in Milestone # (i.e. Milestone 4 in this case).
- Helium-RC0 -> RC# indicates that this bug is targeted to be fixed during the release candidate # timeframe.
- Lithium -> Bugs assigned to the next logical release are not targeted to big fixed in this release or any of its service packs.
If you are looking for bugs to work on or want to see what bugs are targeted for a release you can check out the pre-canned queries below.
- All <project> Helium Bugs -> This search will show you all bugs that are currently "Targeted" to be fixed in the Helium timeframe.
- All <project> Lithium Bugs -> This search will show you all bugs that are currently "Targeted" to be fixed in the Lithium timeframe.
Helium Blocking Bugs (all projects)
- http://goo.gl/UpfX6w. This includes all bugs that are not resolved, have severity blocker or critical, and are not tagged as being targeted for Helium.1, Helium.2, or Lithium.
- If you have a bug that should be there, but isn't, please adjust it to match those criteria.
- If you have a bug that is there, but shouldn't be, please either:
- Change it's target milestone to Helium.1, Helium.2, or Lithium as appropriate.
- Change it's status to RESOLVED if it's been fixed and verified.
- Change it's severity to something other than critical or blocker.
Weekly MD-SAL Call Queries: https://wiki.opendaylight.org/view/MD-SAL_Weekly_Call#Queries