Hi Joel,
Maybe I am just not used to it, but I find bugzilla a real pain in the behind, compared to the one we used to use.
B.
Thus spake swampwallaby:
Hi Joel,
Maybe I am just not used to it, but I find bugzilla a real pain in the
behind, compared to the one we used to use.
That’s too bad. I found the old one incredibly tedious to use. I’ve been
using BZ for years, so am accusotmed to how it works. It might take a
little getting used to.
- How do I easily see all bugs without going through the search screen?
You want a saved search. There’s a box at the lower right after you do a
search, where you can give this search a name and use it again later.
- How do I easily see just my bugs without typing my email address in?
Use the “My Bugs” link.
- Why do we have to type in a full email address when we want to assign
a bug to someone else, as opposed to selecting from a drop down?
Because there could be thousands of addresses to choose from. Once you’ve
typed an address once, it should show up in the completion drop-down.
–
J.
Joel & Brent,
Say I wanted to take a crack at fixing a bug. Where should I pick one from?
If I assign it to myself, will that indicate to you that I’m working on it?
Don’t want to step on one another’s toes…
I came across one the other day that threw a NumberFormatException on “- 2”.
You could argue that the bug was in the module, but we should probably just
have VASSAL strip out whitespace when saving numbers (and to deal with stuff
already out there, maybe even strip out space at runtime).
-K
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of swampwallaby
Sent: August 26, 2010 6:21 PM
To: messages@vassalengine.org
Subject: [messages] [Developers] Bugzilla
Hi Joel,
Maybe I am just not used to it, but I find bugzilla a real pain in the
behind, compared to the one we used to use.
B.
Read this topic online here:
https://forum.vassalengine.org/t/bugzilla/3216/1
Ken,
Yes, assigning it to yourself will show you are working on it.
I would suggest trying to find a bug in an area of Vassal you are interested in.
Stripping out spaces at runtime could be an option in SequenceEncoder.Decoder.nextInt() where you know the token has to be an integer.
As an aside, Joel, I think we need some more status codes to show what point of the bug fix cycle a bug is in, e.g. Investigating, In Progress, Coded, Ready for merge).
B.
*********** REPLY SEPARATOR ***********
On 27/08/2010 at 2:45 PM Ken Stevens wrote:
Joel & Brent,
Say I wanted to take a crack at fixing a bug. Where should I pick one
from?
If I assign it to myself, will that indicate to you that I’m working on it?
Don’t want to step on one another’s toes…I came across one the other day that threw a NumberFormatException on “-
2”.
You could argue that the bug was in the module, but we should probably just
have VASSAL strip out whitespace when saving numbers (and to deal with
stuff
already out there, maybe even strip out space at runtime).-K
What’s the difference between Coded and Ready for merge?
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Brent Easton
Sent: August 27, 2010 7:42 PM
To: messages@vassalengine.org
Subject: Re: [messages] [Developers] Bugzilla
Ken,
Yes, assigning it to yourself will show you are working on it.
I would suggest trying to find a bug in an area of Vassal you are interested
in.
Stripping out spaces at runtime could be an option in
SequenceEncoder.Decoder.nextInt() where you know the token has to be an
integer.
As an aside, Joel, I think we need some more status codes to show what point
of the bug fix cycle a bug is in, e.g. Investigating, In Progress, Coded,
Ready for merge).
B.
*********** REPLY SEPARATOR ***********
On 27/08/2010 at 2:45 PM Ken Stevens wrote:
Joel & Brent,
Say I wanted to take a crack at fixing a bug. Where should I pick one
from?
If I assign it to myself, will that indicate to you that I’m working on it?
Don’t want to step on one another’s toes…I came across one the other day that threw a NumberFormatException on
“- 2”.
You could argue that the bug was in the module, but we should probably
just have VASSAL strip out whitespace when saving numbers (and to deal
with stuff already out there, maybe even strip out space at runtime).-K
How do I search for bugs that are ready to be worked on?
How do I tell the difference between a bug that’s been confirmed as a Java
bug in VASSAL, and a bug that hasn’t been triaged yet?
If I triage an ABR bug, how do I indicate:
Cheers,
Ken
-----Original Message-----
From: Brent Easton
Ken,
Yes, assigning it to yourself will show you are working on it.
I would suggest trying to find a bug in an area of Vassal you are interested
in.
Stripping out spaces at runtime could be an option in
SequenceEncoder.Decoder.nextInt() where you know the token has to be an
integer.
As an aside, Joel, I think we need some more status codes to show what point
of the bug fix cycle a bug is in, e.g. Investigating, In Progress, Coded,
Ready for merge).
B.
Yes, Exactly my point, we need some more status codes and a methodology to use them. My last list I made up off the top of my head without thinking about it too much.
B.
*********** REPLY SEPARATOR ***********
On 27/08/2010 at 9:11 PM Ken Stevens wrote:
How do I search for bugs that are ready to be worked on?
How do I tell the difference between a bug that’s been confirmed as a Java
bug in VASSAL, and a bug that hasn’t been triaged yet?If I triage an ABR bug, how do I indicate:
- It’s a module bug
- It’s a VASSAL bug
- It’s a sun/swt bug or a bug in something else outside our control
Cheers,
Ken
Once a process is decided, I’ll put it up on the wiki. I gather we’re
looking to Joel to help us out with this.
-----Original Message-----
From: messages-bounces@vassalengine.org
[mailto:messages-bounces@vassalengine.org] On Behalf Of Brent Easton
Sent: August 27, 2010 9:35 PM
To: messages@vassalengine.org
Subject: Re: [messages] Bugzilla
Yes, Exactly my point, we need some more status codes and a methodology to
use them. My last list I made up off the top of my head without thinking
about it too much.
B.
*********** REPLY SEPARATOR ***********
On 27/08/2010 at 9:11 PM Ken Stevens wrote:
How do I search for bugs that are ready to be worked on?
How do I tell the difference between a bug that’s been confirmed as a
Java bug in VASSAL, and a bug that hasn’t been triaged yet?If I triage an ABR bug, how do I indicate:
- It’s a module bug
- It’s a VASSAL bug
- It’s a sun/swt bug or a bug in something else outside our control
Cheers,
Ken
Thus spake “Ken Stevens”:
Once a process is decided, I’ll put it up on the wiki. I gather we’re
looking to Joel to help us out with this.
I was hoping we could discuss what we want as a workflow, rather than
having it come entirely from me. 
–
J.
Thus spake “Brent Easton”:
Ken,
Yes, assigning it to yourself will show you are working on it.
I would suggest trying to find a bug in an area of Vassal you are interested
in.Stripping out spaces at runtime could be an option in SequenceEncoder.Decoder
.nextInt() where you know the token has to be an integer.As an aside, Joel, I think we need some more status codes to show what point
of the bug fix cycle a bug is in, e.g. Investigating, In Progress, Coded, Rea
dy for merge).B.
First, I’ll sumarize what we had witht he SF tracker and how we used it:
Status:
Open
Closed
Deleted
Pending
Resolution:
Accepted
Duplicate
Fixed
Invalid
Later
None
Out of Date
Postponed
Rejected
Remind
Won’t Fix
Works for Me
Group:
Awaiting user input
Duplicate
Fixed - Code ready to merge
Invalid buildfile modification
Investigating
Out of Date Module
Out of Date VASSAL
Resolved
The Deleted status we used only for bugs I created when testing the bug
reporter. The Pending status we’ve never used.
Duplicate, Invalid, Works for Me, Won’t Fix, Fixed: These all exist as
resulutions in Buzgilla, and we used all of them before.
Accepted corresponds to ASSIGNED.
I never understood why we had both Invalid and Rejected; the former seems
to imply the latter. We never used Remind.
Later and Postponed are resolutions which could correspond to milestones
in BZ, since they’re used to schedule bugs for fixing at certain times.
None: This is the ‘—’ or blank resolution in BZ.
Out of Date, Out of Date Module, Out of Date VASSAL were all used for
indicating that the problem is already fixed in the current version.
Invalid buildfile modification is a more specific way that a bug can
be invalid, namely that it was caused by a malformed buildFile.
Awaiting user input was used when we had asked a user for more information
and were waiting for a reply.
“Fixed - Code ready to merge” was used when there was a patch ready to
be merged to the trunk.
Investigating was used when we were still trying to figure out what the
problem was.
Here’s what we have in BZ right now:
Status:
UNCONFIRMED
NEW
ASSIGNED
REOPENED
RESOLVED
VERIFIED
CLOSED
Resolution:
FIXED
INVALID
WONTFIX
DUPLICATE
WORKSFORME
MOVED
These come from here,
vassalengine.org/tracker/pag … tml#status,
along with the default explanations.
Everything new comes in as NEW. Noting can ever be UNCONFIRMED, since I
don’t have that feature turned on (turning it on would mean that people
have to vote to confirm bugs before they become NEW).
I don’t see the point of having the REOPENED status.
RESOLVED is useful only if we’re really going to have an additional step
before moving to CLOSED. (I think this is a good thing, as then the person
doing the merging can make the move from RESOLVED to CLOSED.)
VERIFIED is a status that we probably won’t use.
We’re using FIXED, INVALID, DUPLICATE, and WORKSFORME in the way they’re
intended to be used.
MOVED is a status we’ll likely never use ourselves, but BZ’s bug importer
needs this status to exist.
I’ve been using WONTFIX as the resolution for bugs which are in libraries
we depend on, since we won’t be the ones fixing them.
Additionally, I’d like to direct you to the statuses and resolutions that
Fedora uses in its BZ:
bugzilla.redhat.com/page.cgi?id … tml#status
They’ve deleted REOPENED and RESOLVED, and added a bunch of resolutions.
In particular, NEXTRELEASE is one which would fill a need we have.
So, let’s think about what workflow we want. Is it something like this?
–
J.
Thus spake “Ken Stevens”:
How do I search for bugs that are ready to be worked on?
That depends on what you mean by “ready”. In some sense, any bug which
is not an enhancement and not a bug in some external software is ready
to be worked on.
We haven’t categorized the recent bugs by priority yet, so I don’t have
anything except an intiutive sense of what should be worked on first.
(Ideally, those bugs which are reported often would be fixed first, so
as to best reduce the number of bug reports.)
How do I tell the difference between a bug that’s been confirmed as a Java
bug in VASSAL, and a bug that hasn’t been triaged yet?If I triage an ABR bug, how do I indicate:
- It’s a module bug
Assign it to the right Product. Presently, VASL and VSQL are the only
specific modules with their own Product. Right now, I’m putting all the
other module bugs into the “Other Modules” Product.
- It’s a VASSAL bug
Put it under the VASSAL Product. Maybe also assign a Component, as well.
(Another discussion we need to have is what the Components should be. I’m
not at all convinced that the ones I’ve set make sense or are useful.)
- It’s a sun/swt bug or a bug in something else outside our control
Right now, I’m putting these bugs in the “Java bugs” component of the
VASSAL product. I named it that because at present, every such bug I
know of is in fact a JVM bug, but I suppose this isn’t a good name for
the component, since there could be bugs in other libraries which we
also want to track.
–
J.
Also something to consider: We should have some category for the web site. I’m not sure where that should fit in the hierarchy.
Right now we have:
Applications
[list]
[] VASSAL
[list]
[] documentation
editor
GUI
importer: ADC2
installer
Java bug
module manager
player
server
unknown
[/:m][/list:u]
[/:m][*] Modules
VASL
VSQL
Other Modules
[/*:m][/list:u]
By the way, if you haven’t read this page, I suggest you do. I think it’s a
good summary of how Bugzilla is intended to be used.
vassalengine.org/tracker/pag … tml#status
Here’s my proposal for how we adopt this to our workflow. If you approve,
I’ll put it up on the wiki.
Status: NEW
Product: VASSAL
Component: unknown
Version: unspecified
Platform All
Importance: medium
Severity: normal
Assigned To: Joel
Before going any further, let me say that it would be very helpful if there
were a way to auto-populate version and platform.
A) duplicate → Status: RESOLVED, Resolution: DUPLICATE
B) bug in external library → Status: RESOLVED, Resolution: WONTFIX
C) probably a bug in VASSAL → Component: Java bug
D) probably a bug in VASL → Product: VASL
E) probably a module bug → Product: Other modules (I would recommend
avoiding this–VASSAL should never dump a stack trace–even for a missing
image file it should be able to use a placeholder image rather than dumping
stack.)
F) probably not a bug → Status: RESOLVED, Resolution: INVALID (e.g. the
user killed the process with the task manager)
G) can’t reproduce the bug → Status: RESOLVED, Resolution: WORKSFORME
We assign the bug to ourself to work on → Status: ASSIGNED
Status: RESOLVED, Resolution: FIXED
Status: VERIFIED
Status: CLOSED, Target Release: (release version)
-----Original Message-----
On Behalf Of Joel Uckelman
So, let’s think about what workflow we want. Is it something like this?
–
J.
Thus spake “Ken Stevens”:
- Bug arrives as follows
Status: NEW
Product: VASSAL
Component: unknown
Version: unspecified
Platform All
Importance: medium
Severity: normal
Assigned To: JoelBefore going any further, let me say that it would be very helpful if there
were a way to auto-populate version and platform.
It can be done; it would involve some minor modifications to the bug
reporting class and the script which it talks to. I could do this for
the 3.1.15 release, but it won’t help with anything older than that,
since the reporting class won’t know how to report the right values.*
*Unless we have some heuristic on the server side which determine
the version, etc.
Regarding, the platform: I was thinking we’d only set the platform for
platform-specific bugs, not just to indicate the platform on which the
bug was reported.
- One of us triages the bug. This can result in the following outcomes:
A) duplicate → Status: RESOLVED, Resolution: DUPLICATE
B) bug in external library → Status: RESOLVED, Resolution: WONTFIX
I don’t want external bugs to go to RESOLVED, because (1) some of them
we might want to build work-arounds for, and (2) RESOLVED has a “fixed”
connotation to it, which isn’t really correct for bugs like these.
C) probably a bug in VASSAL → Component: Java bug
This convinces me that I’ve misnamed this component, as it’s intended to
be for bugs in Java, not bugs in our code (whihc happens to be written in
Java).
D) probably a bug in VASL → Product: VASL
E) probably a module bug → Product: Other modules (I would recommend
avoiding this–VASSAL should never dump a stack trace–even for a missing
image file it should be able to use a placeholder image rather than dumping
stack.)
There’s a difference between logging a stack trace and having an uncaught
exception which causes a bug report. The missing image stack traces you’re
presumably referring to were logged, but didn’t trigger a bug report.
F) probably not a bug → Status: RESOLVED, Resolution: INVALID (e.g. the
user killed the process with the task manager)
G) can’t reproduce the bug → Status: RESOLVED, Resolution: WORKSFORME
This seems fine to me, with the exception of the handling for external
libraries, and the naming of the default VASSAL component.
- We only get here if it was a bug in VASSAL and therefore is Status: NEW,
Component: Java bugWe assign the bug to ourself to work on → Status: ASSIGNED
- We fix the bug.
Status: RESOLVED, Resolution: FIXED
- The bugfix is merged into trunk
Status: VERIFIED
- The trunk is released as a new version
Status: CLOSED, Target Release: (release version)
Seems like a sensible workflow to me.
–
J.
Thus spake Joel Uckelman:
- One of us triages the bug. This can result in the following outcomes:
A) duplicate → Status: RESOLVED, Resolution: DUPLICATE
B) bug in external library → Status: RESOLVED, Resolution: WONTFIXI don’t want external bugs to go to RESOLVED, because (1) some of them
we might want to build work-arounds for, and (2) RESOLVED has a “fixed”
connotation to it, which isn’t really correct for bugs like these.
How about this:
B’) external bug we can’t work around → Status: ASSIGNED, Resolution: WONTFIX
B’') external bug we can work around → Status: NEW, Component: something…
–
J.
I have created the wiki page for the bug process. Please make changes to
the bug management process by editing the wiki page directly.
vassalengine.org/wiki/Bug_Tracking_Process
I have some responses to your comments below.
-----Original Message-----
On Behalf Of Joel UckelmanBefore going any further, let me say that it would be very
helpful if
there were a way to auto-populate version and platform.Regarding, the platform: I was thinking we’d only set the
platform for platform-specific bugs, not just to indicate the
platform on which the bug was reported.
I’d prefer to have the platform automatically submitted with ABR reports.
- One of us triages the bug. This can result in the
following outcomes:A) duplicate → Status: RESOLVED, Resolution: DUPLICATE
B) bug in external library → Status: RESOLVED, Resolution: WONTFIXI don’t want external bugs to go to RESOLVED, because (1)
some of them we might want to build work-arounds for, and (2)
RESOLVED has a “fixed”
connotation to it, which isn’t really correct for bugs like these.
I disagree with your suggestion that RESOLVED has a “fixed” connotation to
it. RESOLVED means we’re not planning to do any work related to it. I’d
prefer not to clutter our bug list with items we’re not planning to do any
work on.
C) probably a bug in VASSAL → Component: Java bug
This convinces me that I’ve misnamed this component, as it’s
intended to be for bugs in Java, not bugs in our code (whihc
happens to be written in Java).
Can you add a component called “Engine”?
D) probably a bug in VASL → Product: VASL
E) probably a module bug → Product: Other modules (I would
recommend
avoiding this–VASSAL should never dump a stack trace–even for a
missing image file it should be able to use a placeholder
image rather
than dumping
stack.)There’s a difference between logging a stack trace and having
an uncaught exception which causes a bug report. The missing
image stack traces you’re presumably referring to were
logged, but didn’t trigger a bug report.
The ones I saw were ABR bugs. The exception was that an image file was not
found.
F) probably not a bug → Status: RESOLVED, Resolution:
INVALID (e.g.
the user killed the process with the task manager)
G) can’t reproduce the bug → Status: RESOLVED, Resolution:
WORKSFORMEThis seems fine to me, with the exception of the handling for
external libraries, and the naming of the default VASSAL component.
- We only get here if it was a bug in VASSAL and therefore
is Status:
NEW,
Component: Java bugWe assign the bug to ourself to work on → Status: ASSIGNED
- We fix the bug.
Status: RESOLVED, Resolution: FIXED
- The bugfix is merged into trunk
Status: VERIFIED
- The trunk is released as a new version
Status: CLOSED, Target Release: (release version)
Seems like a sensible workflow to me.
–
J.
messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages
Responses below
-----Original Message-----
Joel UckelmanHow about this:
B’) external bug we can’t work around → Status: ASSIGNED,
Resolution: WONTFIX
I prefer external bug we can’t work around → Status: RESOLVED, Resolution:
WONTFIX
ASSIGNED bugs don’t have resolutions. Only resolved bugs have resolutions.
B’') external bug we can work around → Status: NEW, Component:
something
Per my other e-mail, how about “something” being “Engine”?
Thus spake “Ken Stevens”:
How about this:
B’) external bug we can’t work around → Status: ASSIGNED,
Resolution: WONTFIXI prefer external bug we can’t work around → Status: RESOLVED, Resolution:
WONTFIXASSIGNED bugs don’t have resolutions. Only resolved bugs have resolutions.
Ok, you’ve convinced me.
B’') external bug we can work around → Status: NEW, Component:
somethingPer my other e-mail, how about “something” being “Engine”?
We talked about this over IM and decided to use the “Player”, “Editor”,
“Module Manager” components for this.
–
J.
I did some rejiggering of the Classifications, Products, and Components on BZ, namely:
This seems cleaner overall, but there’s one downside I’ve noticed, which is that components can’t have their own version numbers. Hence, this prevents modules from specifying their own version numbers in BZ. This might only be a problem for VASL bug reports, or maybe no one cares. I haven’t deleted the VASL and VSQL products yet in case anyone has a strong opinion on this.
- One of us triages the bug. This can result in the following outcomes:
A) duplicate → Status: RESOLVED, Resolution: DUPLICATE
B) bug in external library → Status: RESOLVED, Resolution: WONTFIX
C) probably a bug in VASSAL → Component: Java bug
D) probably a bug in VASL → Product: VASL
E) probably a module bug → Product: Other modules (I would recommend
avoiding this–VASSAL should never dump a stack trace–even for a missing
image file it should be able to use a placeholder image rather than dumping
stack.)
F) probably not a bug → Status: RESOLVED, Resolution: INVALID (e.g. the
user killed the process with the task manager)
G) can’t reproduce the bug → Status: RESOLVED, Resolution: WORKSFORME
Case E applies where there is a bug in custom code within the module that may well be causing a stack trace and bug report. Are we planning to add every module as a component as we attribute errors to them? I don’t seem to have access to do this.
Note that Missing Images are currently dumping a stack trace to the log file but NOT generating a bug report. There are so many images missing from so many modules that every bug report is full of them. Joel, I suggest we stop missing images generating stack traces, it is pointless and just makes looking through log files far more difficult than it needs to be.