Personal tools

Issue Tracking

From OpenLaszlo

The OpenLaszlo project uses JIRA for issue tracking and project management: http://openlaszlo.org/jira/browse/LPP.

If you have encountered bugs in the OpenLaszlo platform, please consider looking in the JIRA database for a description of your bug, and entering one if a description and a test case if there's not one there. If you are interested in contributing to the OpenLaszlo project, please take a look at the unassigned bugs on the list. If you have a minor fix for a bug, you can send it to the mailing lists, or add it to the bug report and click "Start Review" on the left column. If you have a major fix, please read the Contribution FAQ.

The milestones used in JIRA are described on the platform roadmap wiki page.

[edit]

Jira Workflow

Here is the current bug tracking workflow:

Image:Bug_workflow.png

[edit]

Jira Etiquette

1

When you submit a change for review PLEASE note the bug number AND the bug description for the bug you are fixing. Call me paranoid, but it is too easy to type-oh the number, and without the description, we might never figure out what the real number should be. The recommended format is (from http://wiki.openlaszlo.org/Change_Description_Template): 

 Bugs Fixed: LPP-5678 Only right-handed gimlets are supported
2

When you check in your change using svn-commit (assuming you have updated your tools from http://svn.openlaszlo.org/tools/trunk), you will notice that it outputs the svn log for that change with the admonition: 

  Remember to update any Jira entries for bugs that are fixed by your
  change by pasting the log message just above into Jira as the comment when
  resolving the bug.  Also update the Fixed in Change# field with your
  revision number: 123456.

It's really helpful if you do what it asks (and keep doing it if the bug gets re-opened or you find you have to make additional changes to completely fix the bug). Then if we decide to integrate your bug fix to a branch, it is easy to find all the changes related to that bug.

2a

Update the Fixed in Change# field to the last change that relates to this bug. That way, someone who is testing or using a trunk build can compare the trunk's build (as canvas.lpsbuild or Debug.versionInfo() reports): 

 Build: trunk@12978 (12987)

to determine if that bug should have been be fixed in this build. The build id is read as follows: 

 <branch>@<last change in that branch> (<last change in the entire svn repository>)
2b

Update the Actually Fixed In field to reflect all the branches that the fix has been applied to. Normally this will just be the branch labeled TRUNK, but changes that are targeted to be migrated to released branches will have those branches listed in their Fix Version/s field and normally the build manager will take care of integrating those changes to the branch and noting the branch in the Actually Fixed In field. If you have been tasked with integrating a change to a branch, be sure to use multiple-selection to add the branch to the Actually Fixed In field.

Because of the limitations of Jira, we can't make these various fix fields really encode what we want. As a result, to determine if a bug is fixed in a branch build that you are running, you have to both know that the build version is greater than the fix version marked in the bug _and_ that the bug is marked as actually fixed in the branch. For an exact determination, you will have to consult the Jira comments and examine the svn log output there.

Retrieved from "http://wiki.openlaszlo.org/Issue_Tracking"