A forum for technical support discussion related to Fogbugz.
How do all of you handle this situation:
A developer has a bunch of bugs assigned to them, and they go through them, correcting them one by one in their own private branch, and marking them Resolved. They commit all of these changes when they're done.
The problem is that until the changes are committed, nobody else can see the bugfixes. So the person who open the bug looks gets the email that it's fixed, tries to check it, and seeing it's not fixed, re-opens it?
So the question is:
1) Is it best to perform separate commits for each bug? It seems to me there would be an explosion of commits this way, for every little change.
2) Or should developers keep track on their own of which bugs they have fixed and resolve them as a batch when they do their big commit for the day?
If you are doing daily builds the answer is easy. The day after you resolve the bug, you can verify it is fixed.
If you do other types of builds, I usually just note in my resolution something like "pushed in tomorrow's build" or "fixed in next build"... so the opener knows to wait a bit before resolving.
We have recently ran into the same problems while in the middle of porting an application to SQL. Programmers are resolving tickets quickly but we do maybe 2 builds a week. The testers are getting the tickets back before the build were being posted and reactivating the tickets. We decided to add the version number in the notes of the ticket, this way before they test the app they compare the version number on the current build with the version on the ticket.
No perfect, but the communication is key!
Thursday, December 21, 2006
This topic is archived. No further replies will be accepted.Other recent topics