Version 4 (modified by 17 years ago) (diff) | ,
---|
Ticket Life Cycle
As of FCKeditor 2.5, every line of code introduced in the FCKeditor/trunk tree must pass through a more strict review process. This guarantees the overall quality of the code base.
This document describes the life cycle of a ticket in the FCKeditor project.
Ticket Creation
Anyone is allowed (and invited) to open tickets for every single issue faced in FCKeditor. The Bug Reporting Instructions and Feature Request Instructions pages have more information on how to properly fill new tickets.
Clean up
The ticket title, its description or its fields could be cleaned up to confirm to our internal requirements and recommendations.
Confirming Bugs
Someone from the core development team should then check the ticket information and decide whether it has enough useful information to move forward.
The following actions could be taken when confirming a ticket:
- Resolve the ticket as "duplicate" if the ticket is determined to have the same cause as a ticket reported earlier. The "DUP of #XYZ" comment should be added, pointing to that ticket.
- Mark the ticket with the "WorksForMe" keyword if the bug seems to not be present in the current trunk code. A comment should be added instructing the reporter to check it again and provide more information. A "WorksForMe" ticket expires in 30 days if no action is taken in the ticket, resolving it as "worksforme".
- Resolve the ticket as "invalid" if it does not describe a problem with FCKeditor.
- Resolve the ticket as "wontfix" in the rare cases that the bug seems valid but there's a specific reason why it should not (or cannot) be fixed. If the reason is something we can't workaround, the "CantFix" keyword should be used.
- Mark the ticket with the "Pending" keyword, if the ticket does not have enough information to move forward, asking the reporter for more details. A "Pending" ticket expires in 30 days if no action is taken in the ticket.
- Mark the ticket with the "Confirmed" keyword. For browser specific tickets, the relative keyword should be appended: "IE", "IE7", "Firefox", "Safari" and "Opera".
- Mark the ticket with the "HasPatch" keyword, if a patch or descriptive code changes is provided, even if not analyzed and reviewed.
Analyzing
Once confirmed, the research starts to identify the source of the problem. A core developer could "Accept" the ticket, indicating that work is already in progress for it, avoiding duplicated work.
The assignee, the reporter or other could come with some more information at this point, to help on the analysis research and coding.
Proposing Patches
A proposed patch should be added as a new attachment to the ticket. It must be a valid SVN patch file, named XYZ.patch, where "XYZ" stands for the ticket number. The "Review?" keyword should be appended to the ticket, indicating that the patch awaits review.
If the submitter of a patch changes their mind about wanting a review, the review keyword should be removed.
The "HasPatch" keyword, if available, should be removed at this point.
When a submitter proposes an updated patch, the previous patch should still remain in the ticket. The new patch should be named "XYZ_n.patch", where "n" is a progressive number starting from "2". The new patch makes previous ones obsolete. The review flag should be set to "Review?" again, with instructions to the reviewer.
Reviewing Patches
A reviewer will read through each proposed patch. If the patch is ready to commit, the reviewer will change the review keyword to "Review+".
A patch might not be ready to commit for various reasons. The bug fix might be incorrect. The coding style might be incorrect. The reviewer should always explain in detail why a patch is not ready to commit, so the submitter or someone else can revise the patch. The review keyword is changed to "Review-" at this point.
Commit
After a patch has been reviewed, someone with commit privileges in the source repository will commit it. The ticket is then resolved as "fixed", pointing to the relative changed with a message like "Fixed with [XYZ].".
If the assignee or the patch developer has commit privileges, he/she has the preference to commit it.