gEDA/gaf and PCB Bug/Feature Request Triage Guide

gEDA/gaf uses Launchpad for bug and feature request tracking - the gEDA landing page is here.

Newly filed bugs and feature requests must be triaged periodically by the developers and others close to the project, in order to progress them smoothly through development and avoid them getting stuck.

Anyone who wants to help triage bugs for the community, please apply to join the geda-bugs team for gEDA/gaf and/or PCB.

Triaging bugs

  1. Choose a bug from
  2. Grab “git HEAD” of whichever package the bug is in (if you don't have it already) and try to confirm whether the bug is still present or not. (http://git.geda-project.org)
  3. If the bug is still present, move the status from “New” to “Confirmed”
    • If and only if there is a good testcase uploaded that reproduces the bug (or you have created and uploaded one as part of triage), you can move the status to “Triaged”
    • Note: it is not good form to mark your own bug “Confirmed”.
  4. If the bug is absent, make a comment and set the status to one of
    • “Invalid”, if you are confident that the bug is bogus or misfiled.
      • If the bug is tagged with “sf-patches” shouldn't be closed “Invalid”. If the patch cannot or will not be accepted, mark it as “WontFix”.
    • “Fix Committed”, if you believe a fix has been committed in git since the last release;
    • “Fix Released”, if you believe a fix has been committed that has been in a released version;
    • “Incomplete”, if you ask the reporter a question which needs to be answered to properly assess the bug.
  5. If the bug affects you personally, hit the link under the title of the bug that lets you state that.
  6. If you want to be emailed when the bug is modified, click “Subscribe” on the right hand toolbar.

Triaging Feature Requests

  1. Choose a feature request from
  2. If it's not already set, set the Importance to “Wishlist”
  3. If you agree with the feature request, select the “Bug affects me” option. This will allow us to track the popularity of a request.
  4. A developer who is sufficiently familiar with the design issues will move the Status from “New” to either “Confirmed”, “WontFix” or “Opinion”.