Defect tracking of patches
We have a defect tracking system which tracks new developments, internally and externally raised incidents and patch requests.
Our process is that if an incident is raised and requires a patch then a fix must go into the latest version of the software before the patch (for an earlier version) can be produced. The incident is raised in our bug tracking system and if a patch is requested a box is ticked.
QA will usually test the patch before the main fix (as it is usually more [stupid is as stupid does]) but I can't work out how to record the status of the patch on the incident separately from the status of the main incident. Obviously the support desk are more interested in the status of the patch whereas development s interested in the status of the main fix.
We only have the option of setting one workflow step for each incident.
Sorry if this is not clear but I really need some advice on what to do now. Feel free to ask any questions if I've confused you.
Re: Defect tracking of patches
Is sounds as if you have at least 2 code trees. N_released and N_main (or in production). The simplest solution may be to split your defect tracking system the same way you split your code base. This of course means 2 separate defect databases to work in.
Another solution might be to enter 2 defect reports and link them. (I don't know the capabilities of your defect tracking system, but in our system where defects span product groups linking bugs is very beneficial to track one problem across multiple releases/products.)
Another alternative is to make your devs repsonsible for tracking the update as a work items/tasks, and log the issue as a dev work item for main (in-production) build, and enter the issue in the defect database. Once the patch is completed and released the issue can be closed. The key here is that this then becomes a regression test ran on the main build. (Of course this might imply that your process changes.)
One a different note...your process sounds a bit awkward. Of course you would likely want the 'fix' to get prop'ed to the in-work version, but depending on the complexity the effort may actually take more work than producing a patch for released version. But, I suspect your customers probably want the patch yesterday, and wouldn't be too happy to learn that they are actually second in line. But, that is a process problem for your management to figure out. Dev centric process are generally dev centric in getting the next version out the door; not end-use customer focused in maintaining what has already shipped.