Page 1 of 2

On bug reports

PostPosted: 15 Jun 2011, 13:24
by UnderFlow
The way bug reports are currently being handled is quite chaotic. There are two long threads as well as the Google Code issues page. Bugs that cannot be fixed on the spot appear to be forgotten or multiply reported by different people.
I'd like to suggest moving all reports to a single bug-tracking platform. What are your thoughts on this?

Re: On bug reports

PostPosted: 15 Jun 2011, 14:00
by friarsol
UnderFlow wrote:The way bug reports are currently being handled is quite chaotic. There are two long threads as well as the Google Code issues page. Bugs that cannot be fixed on the spot appear to be forgotten or multiply reported by different people.
I'd like to suggest moving all reports to a single bug-tracking platform. What are your thoughts on this?
I tried this at some point without any luck, and the Google Code Issue tracker is used partially for longer term features. Bugs will always be reported multiple times (even with a bug tracking system in place) if they are of moderate enough size. But it would be handy to actually use the Issue tracker on google code for everything, so people won't feel like complex bugs (like multi-targeting/multi-triggering which was a fairly substantial) aren't just being ignored.

Re: On bug reports

PostPosted: 15 Jun 2011, 18:07
by Jaedayr
I am in favor of trying to add some more order to bug reporting and resolution. Keeping it very easy to report bugs is important, so folks will participate in the process.

What about someone regularly reviewing the two major forum threads and adding new issues as they appear? Then we train all the developers to update/close issues as they commit changes. :) Eventually we might get to the point that everybody is required to post issues, but for now, what if we take the feedback we are getting and try to consolidate and work with that. I am much better at finding bugs than I am at fixing them currently, and I will volunteer to help keep the issue list as current as it can be, if we want to head in that direction.

Is there a way to add more fields to the issue database? For example, the revision number would be good info to have. Also, is there any way to link issues to commits, so that a commit could also update the issue?

Re: On bug reports

PostPosted: 15 Jun 2011, 18:55
by UnderFlow
The problems I see with Google Code are:
  • It is not visible enough. If you are a normal Forge user who doesn't know it exists, you are unlikely to find out.
  • Most people are not used to bug trackers. Their inhibitions would be increased.
  • No mouse-over / autocard function.

If a consensus is reached for its usage, I suggest making a sticky in the forum with a link to the Issues page, as well as a tutorial with screenshots. The exception report message within Forge should also be changed accordingly.

Re: On bug reports

PostPosted: 15 Jun 2011, 19:09
by friarsol
UnderFlow wrote:The problems I see with Google Code are:
  • It is not visible enough. If you are a normal Forge user who doesn't know it exists, you are unlikely to find out.
  • Most people are not used to bug trackers. Their inhibitions would be increased.
  • No mouse-over / autocard function.

If a consensus is reached for its usage, I suggest making a sticky in the forum with a link to the Issues page, as well as a tutorial with screenshots. The exception report message within Forge should also be changed accordingly.
Does Google Code have an API for the issue tracker we can use? Maybe we can just have a menu button inside of Forge that pops up and will let users fill out reports that way? It would solve your 1st two issues. We could probably even get more relevant information since we might be able to embed lots of game state data in as well. It would be some work to put it together, but it'd streamline the process along with giving us useful information to help debug?

Re: On bug reports

PostPosted: 15 Jun 2011, 19:39
by friarsol
Ok.. here are is the API in Java if we wanted to do that: http://code.google.com/p/support/wiki/I ... kerAPIJava

Overflow, what bug tracker were you going to suggest? There's no need for it to be google code, if it's simpler to do it somewhere else.

Re: On bug reports

PostPosted: 15 Jun 2011, 21:23
by UnderFlow
friarsol wrote:Overflow, what bug tracker were you going to suggest? There's no need for it to be google code, if it's simpler to do it somewhere else.
I have almost no experience with trackers and apparently they are all pretty similar anyway. I'd stick with Google Code since it is already set up and the Java API sounds cool (I could not find an equivalent for Sourceforge). Does anyone have a more sophisticated opinion on this?

Re: On bug reports

PostPosted: 17 Jun 2011, 12:57
by timmermac
Wasn't somebody on the forums keeping track of this sort of thing at some point? I think it was freestorageaccount.

Re: On bug reports

PostPosted: 17 Jun 2011, 13:50
by friarsol
timmermac wrote:Wasn't somebody on the forums keeping track of this sort of thing at some point? I think it was freestorageaccount.
Yea he did for a few months around September-November ish. It's better if we let technology keep track of things.

Re: On bug reports

PostPosted: 17 Jun 2011, 13:55
by Chris H.
timmermac wrote:Wasn't somebody on the forums keeping track of this sort of thing at some point? I think it was freestorageaccount.
`
We have had two different people attempt to maintain a bug listing at one point or another. Unfortunately, the amount of time and dedication that is required for this type of idea to work can be overwhelming.

Re: On bug reports

PostPosted: 19 Jun 2011, 23:26
by UnderFlow
There was no response suggesting a better platform, so I'll just go ahead and create a tutorial for Google Code. What do you think about this draft?


How to file a bug report via Google Code | Open
  • Go to http://code.google.com/p/forge-card-game/issues/list.
  • Get a Googlemail account if you don't have one already.
  • Search for existing open issues with key words from your bug report (e.g. "Sphinx-Bone Wand"). If an issue describing your bug does already exist, you can provide additional information in its comment section.
  • Post your issue by clicking on "new issue". You will receive a template that you can fill out. Under "version", write the release date of the beta (e.g. "BETA 06/12/2011") or the revision you used to compile your Forge version if you use the SVN (e.g. "Revision 9875"; command: "./svn.exe info forge-svn").
    forge_tut_1.png
  • If there are news regarding your issue, you will automatically be notified via your Googlemail address.

Re: On bug reports

PostPosted: 20 Jun 2011, 07:37
by Sloth
UnderFlow wrote:There was no response suggesting a better platform, so I'll just go ahead and create a tutorial for Google Code. What do you think about this draft?


How to file a bug report via Google Code | Open
  • Go to http://code.google.com/p/forge-card-game/issues/list.
  • Get a Googlemail account if you don't have one already.
  • Search for existing open issues with key words from your bug report (e.g. "Sphinx-Bone Wand"). If an issue describing your bug does already exist, you can provide additional information in its comment section.
  • Post your issue by clicking on "new issue". You will receive a template that you can fill out. Under "version", write the release date of the beta (e.g. "BETA 06/12/2011") or the revision you used to compile your Forge version if you use the SVN (e.g. "Revision 9875"; command: "./svn.exe info forge-svn").
    forge_tut_1.png
  • If there are news regarding your issue, you will automatically be notified via your Googlemail address.
Looks very understandable to me. We should give it a try. Thanks UnderFlow.

Re: On bug reports

PostPosted: 20 Jun 2011, 18:20
by Chris H.
UnderFlow wrote:There was no response suggesting a better platform, so I'll just go ahead and create a tutorial for Google Code. What do you think about this draft?


How to file a bug report via Google Code | Open
  • Go to http://code.google.com/p/forge-card-game/issues/list.
  • Get a Googlemail account if you don't have one already.
  • Search for existing open issues with key words from your bug report (e.g. "Sphinx-Bone Wand"). If an issue describing your bug does already exist, you can provide additional information in its comment section.
  • Post your issue by clicking on "new issue". You will receive a template that you can fill out. Under "version", write the release date of the beta (e.g. "BETA 06/12/2011") or the revision you used to compile your Forge version if you use the SVN (e.g. "Revision 9875"; command: "./svn.exe info forge-svn").
    forge_tut_1.png
  • If there are news regarding your issue, you will automatically be notified via your Googlemail address.
`
Looks good to me. Thank you.

In recent beta releases we have included a short readme file and I can add your instructions to this file. It may help.

Re: On bug reports

PostPosted: 21 Jun 2011, 22:19
by Jaedayr
I just submitted my first bug report and have two observations. First, I miss the ability to see the card text that we have on these forums when you mouse over a card name. Second, are we requesting that whoever does a commit to address an issue also update the issues log? Should the issue number be included in the commit comment?

Re: On bug reports

PostPosted: 07 Jul 2011, 15:19
by Braids
based on the positive feedback above, i have started to use the google issue tracker. most of my work involves enhancement and architecture, anyway.
Jaedayr wrote:I just submitted my first bug report and have two observations. First, I miss the ability to see the card text that we have on these forums when you mouse over a card name.
the tracker automatically recognizes urls/hyperlinks in the problem description at least. you can link to the forum topic or specific post from there, and you can link to cards on magiccards.info/gatherer/whatever.
Jaedayr wrote:Second, are we requesting that whoever does a commit to address an issue also update the issues log? Should the issue number be included in the commit comment?
i think this is a good idea. perhaps not a requirement. at least not at first. sometimes one commit may contribute to multiple issues, too, so we need to keep that in mind.

i have heard of locking revision systems that require one to enter an issue or list of issues before editing a file, instead of before committing. this wouldn't work with svn. googlecode's version doesn't even support locks. or maybe i don't have locking privileges. i tried to lock files last week and it didn't work. anyway. unimportant.