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.
Jira Workflow
Here is the current bug tracking workflow:
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 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 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
The Fix version/s field is a little messy just now, because for an open bug it means where we want it fixed and for a closed bug it means where we fixed it. If your bug is just being fixed in trunk, this field should have the version trunk is targeted for selected (i.e., 4.2.1 as of this writing). If your bug is targeted for integration to a branch, to be completely pedantic, you should close the bug in trunk and then re-open it, assigning to the branch manager, and add the branch to the Fix version/s.
- 2c
Finally the Fixed in branch field should be set to trunk, since that's where you have fixed it. If the fix is to be integrated, the branch manager will set it to the branch it was integrated to, once that has been done, and also update the Fixed in Change# field to the revision the integration was made at. ___
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 fixed in the branch.
