Specifiy source change sets numbers when reporting issues

Sep 21, 2010 at 5:42 PM

We have not formally discussed it, but I think we should standarize on reporting the changeset of the source code, when we create an issue.  I think a little more detail can help save some time when reproducing issues.  Thoughts?

Sep 21, 2010 at 5:45 PM

@erichexter I'm fine with that. I hadn't bothered thus far because it's really only been David and Luan making changes, but as more people start to contribute it certainly can help avoid wasted time trying to repro something that's been fixed since the work item was created.

Sep 21, 2010 at 5:48 PM

Did you mean specifying the changeset when you mark an issue as fixed? I can’t imagine you know the changeset when you create an issue.

Totally agree.

CodePlex plans to implement better support for this too. When you commit a change, ideally your commit message should mention the issue too.

“Fixed Issue: 123 blah blah blah…”

Sep 21, 2010 at 5:50 PM

I was looking at it more from the point of developers and community people working on a fork and they may discover an issue without having synced changes that other developers have that are in flight.  It may not be as important was the code stabilizes. It seems like the issues have been updated in the comments with the change set of the commits as well as the check in comments have references the issue numbers, so that has been great.

Sep 21, 2010 at 5:53 PM

Maybe I’m being dense (or most probably), but I don’t understand the scenario you’re describing.

Sep 21, 2010 at 5:57 PM

@haacked, I always know the commit in which I am testing. Right now, it's 7e249a6783ef, 'cause I haven't pulled changes into my fork this morning yet.

Sep 21, 2010 at 11:26 PM

Oh, and for those that don't know, to see what your local revision is, type `hg identify`.