-
Notifications
You must be signed in to change notification settings - Fork 2
Redmine workflow.md
We organize work into milestones and tickets. The milestones represent related work or work that is targeted for a particular date or event. In general, code is released as soon as it is tested and merged to master. The milestones capture the goals for an upcoming event.
Commits to github should reference related tickets. When developers are fixing bugs or adding ticketed features, they should name their bugfix branch with the ticket number and reference the ticket in the commits as explained here: Referencing-issues-in-commit-messages.
When a pull request is issued, the pull request should be linked in the ticket.
In general tickets pass through the following workflow
new -> in progress -> (developer done) -> testing -> (failed testing) -> closed
- in progress: the tickets is being worked on. developers should assign themself to the ticket
- developer done: this is an optional state to be used if the work is done, but the developer cannot get the fix on the testing server. Don't bother with this state if the ticket is on the testing server.
- testing : the ticket fix should be on the testing.oerpub.org server. It can also be on another testing server, in which case the server's name should be included in the last comment to the ticket.
- closed : Right now the closed state means that testing has passed. Whether the fix is released depends on whether the code was merged into master (in which case it is either released or very soon to be released) or whether it was merged into a milestone branch for release as a unit with other changes.