How to approach solving a bug/Feature/Task (developers)

Before starting

When a developer is going to face the resolution of a bug, the first thing to do is to assign it to himself (if it had not been already assigned) and then accept it. This way other developers will be informed that there's someone working on the subject.

Remember that on the stable branch or during the stabilization period approaching the resolution of a Ticket should not be faced without knowledge / consent of the responsible / coordinator of testing.

The bug will then pass to assigned (state of a ticket) and the developer will be able to start solving the problem.

Communication

If during this process the developer needs to communicate with the tester or someone else, he has to add, on the CC field, the users / addresses of those who need to be informed and write the comment in the ticket itself.

Communications between tester and developer should take place through the comments of the Ticket so that everything is monitored. If there were other communication, it should be reflected afterwards on the ticket, at least just a summary.

Within the ticket comments anyone can refer to another ticket using the following format:

{abr_trac}:#{numero_ticket}

Where:

• abr_trac :Optional, required only if the ticket is from another trac. Trac Abbreviation where the ticket is published. Usually Bugtracking bug or core for gvSIG Core. For other Tracs please ask.
• numero_ticket :Reference Ticket number.

Upload changes

When the developer needs to make changes on a project on which he has no permissions, in order to accomplish the task, He has to attach a patch to the ticket and reassign it to a developer who has permission to do so.

When you upload any changes to the repository, in the commit commentary should be included a reference to the task that caused it. This should be done with the following format:

{comentarios del cambio}

{abr_trac}:#{numero_ticket}

Where:

• abr_trac : Trac Abbreviation where the ticket is published. Usually Bugtracking bug or core for gvSIG Core. For other Tracs please ask.
• numero_ticket : Reference Ticket number.

This way the changes will be linked to the ticket. By uploading these changes, the SVN generates some change numbers or changeset that identify the modifications uploaded to the repository. These changeset, to maintain the link, should be noted in the comments of the ticket with the following format:

{Comentarios}

SVN {Rama} [gvsig {numero_changeset}] [gvsig {numero_changeset2}] ...

Where:

• Branch : SVN Branch where changes were made. Normally trunk or branches/v10.
• numero_changeset : Change identifying number in the repository. This number is displayed on the SVN console when doing the commit otherwise you can find it with Team / Show resoerce history of modified files.

    * Note*: To facilitate the monitoring it is advisable to try to group commits whenever it is posible.

Close the task

If the bug is solved, the developer has to set it as fixed and fill the fields resolve version and resolve build number. This data can either be found by looking at the page stage test of the version (the next to the last one generated) or, in case of doubt, asking the person responsible for packaging or distribution.

Under no circumstances the tester should change the value of the fields version or build number.

If the bug can not be fixed the developer will set the resolution to wontfix and leave the fiels resolve version and resolve build number blank

If the bug is duplicate this must be set on the field resolution and in the comments include a reference to the ticket where it was resolved. To refer to another ticket see the Communication section of this page.

Every time you fix a bug, or perform any important task that is going to be included in a gvSIG bug, the developer, in addition to updating the corresponding ticket, should add to the page test phase of the affected product the link to the ticket in the appropiate version / build, the link title will be the same as the ticket, or a note that reflects the job he has done. This way, testers can adequately validate the work done. This action must be performed for each of the tickets / bugs corrected.