Severe bugs have a higher priority and so should be targeted earlier, but
we should not just address high priority bugs. Finally we can assign the bug to a
developer to actually fix.
Now our process relates more clearly with the one for features. However, branching
for bugs is slightly different. Since we are dealing with code that already exists we
will probably not want to branch from the HEAD revision of the trunk, but rather an
earlier revision. Finding the right revision can be an issue, but we have already seen
the solution for this??”tags. As bugs are generally filed against a particular version or
milestone of our application, then being able to branch from the relevant tag makes
life much easier. As before our branch name and log should reference the ticket
number, e.g. for ticket #51 we could call our branch bug-51 and our commit log
would be something like "Branched to fix ticket #51 ??“ Crashes when saving.".
We can now use our branch to find and fix the bug. Determining exactly how to fix
a bug is not always obvious, and once again Trac helps us with this. Tickets can be
used to track the dialog relating to that ticket, and we can use this along with the
code browser to obtain help from other developers in our team to pinpoint the cause
and find a solution.
Pages:
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111