Home
Submitted by aklis on Fri, 03/06/2015 - 00:36

bugtracker-proposal

Trisquel bug workflow proposal

After the last development meeting, we ackownledged to revisit the workflow used in the bugtracker. This is my idea, feel free to add any comment or question.

This is a quick draft of my idea, with the new fields and a brief description, so we have something to start with.

Projects

  • Trisquel: Confirmed trisquel bugs
  • Webs: Issues related with web usages, not only for the main trisquel.info site but also for devel.t.i and others
  • User support: Bugs that don't need any code change, only user configuration/guide. Should be limited to cases where a new package version is not needed.

Categories

  • Problem: In case of doubt, the default category
  • Bug: Confirmed bug
  • License problem (or FDSG?): Problems with the Free Distributions Software Guidelines
  • Feature: Improvement over current situation (importing packages from ppas, improve docs...)
  • Branding: Branding issue
  • Upstream: Bug assigned to upstream to be fixed, expected to reach trisquel on next upstream version. There should be a link to the upstream bugtracker

Components

  • Trisquel: packages in the default trisquel install
  • Trisquel Mini: packages in the default trisquel-mini install
  • Sugar: trisquel sugar packages (TOAST)
  • Installer: Problems with the installer, or installation issues
  • Packages: issues with packages not in the default install, but in trisquel repos
  • Abrowser: abrowser related bugs (I think it needs it's own component...)
  • Translation:
  • Documentation:

Status

  • New: First status to be used
  • Confirmed: set by other user, not the author. For most software bugs, in order to set it the description or comments have to include:
    • source package and version
    • steps to reproduce
    • expected result
    • obtained result
  • WIP: someone is tracking it down
  • Patch ready: Patch is ready and merge request was sent in devel.t.i
  • Duplicate: There is another bug reported, remember to set the id of the original bug
  • Fixed: There was an action from our part
  • Closed: There wasn't any action from our part

Bug priorities

  • minor: doesn't affect common usages. Branding bugs should have this priority
  • normal: obtained result is different from the expected one
  • critical: normal usage is not possible
  • regresion: Used when something that was working before, is now broken. It needs to have previous package version, and buggy one

Sample run

Using https://trisquel.info/en/issues/13379 as example

Stage Project Category Component Status
1st Support Feature Trisquel New
2nd Trisquel Bug Confirmed
3rd WIP
4th Patch ready
5th Fixed

(Some of those states/stages could be avoided, but are shown here for clarity)

Questions

Add your own, this is a wiki ;)

Revisions

03/06/2015 - 00:36
aklis
aklis