This page shows, how the workflow of submitted tickets will be, why they change their state from one state to another and under which conditions patches are committed into the repository in a fast way.
After a ticket is submitted, one of the ticket dispatchers reviews the ticket. If the reported bug is not reproducable, if it is an invalid request or if it is a duplicate ticket, the ticket gets closed. Otherwise the dispatcher looks if there are architectural changes to be made in the design to solve the ticket. If so, the ticket advances to an Design decision state. Otherwise it bypasses this state and goes directly to the accepted state.
If the dispatcher thinks, a new feature, a patch or a bugfix could interfere with the current design, one of the core developers has to check which changes have to be made to the design to solve the ticket. If the core developer thinks that the needed changes comply with the design, the ticket will be accepted. Otherwise it will be closed and the ticket changes the state to OK by design.
Once the ticket was accepted, one of the programmers has to provide a patch if it was not already submitted by the creator of the ticket. In this case, the patch just gets reviewed and possibly fixed. In a case of a low-priority patch on a non-critical bug, the patch might get on hold if it does not comply with standards.
After all programming is done, the documentation is up to date and all unit tests are passed, the ticket advances to the ready for core team state.
Ready for core team
When a ticket has reached the ready for core team state, it needs to be approved by one of the core developers. If there is an issue, i.e. missing documentation or bad coding style, the ticket goes to the patch rejected state to be reviewed by the programmer. If there are no issues, the patch is committed to the repository and the ticket switches to state fixed.
A ticket can get the state patch rejected if there is an issue with the patch. This can happen because of missing, incomplete or incorrect documentation, bad coding style or failed tests. The developer needs to review the patch and solve all the issues. After that, the ticket changes its state back to ready for core team.
In a case that a submitted bug cannot be reproduced, the ticket changes its state to cannot reproduce and is closed. If the submitter thinks that this is incorrect, he can reopen the ticket and provide additional information. In this case the ticket changes its state to Unreviewed.
If there is more than one ticket regarding the same issue, all but one get closed in the state duplicate.
All tickets that do not belong into the ticketing (i.e. Spam, problems with external libraries, ...) are closed with the state invalid.
OK by design
If a core developer who has to do a Design decision thinks that the design is ok, or if the design shall not be changed to solve a minor problem, a ticket is closed and gets the OK by design state.
Once a bugfix is committed into the repository, the corresponding ticket switches to the state fixed and is closed.
- png_1.png (50.8 kB) - added by Grypho on 09/23/07 09:57:56.