Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Issue tracker clarifications

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] Issue tracker clarifications
  • Date: Tue, 17 May 2005 10:05:37 +0100

John Schinnerer wrote:
Aloha,

Just want to clarify what you have written. Flow diagrams
for passage of issues

(bug,new) -> (bug, open) -> (bug,resolved) -> (bug,closed)
^ |
|- new build <--

The problem with this diagram is that we only take the developers word that a bug is resolved, before the build is OK to release.

Surely we need to have the tester in the process, and indicated by the issue tracker.

I will add making a simple visual flowchart for this for the testing docs to my to-do list...

The path from resolved to closed would also go through 'new build', if by 'new build' you mean the bug is regressed against the new build.

1. A developer makes a fix in code that will be part of the next release, sets status to 'resolved' and assigns bug back to the tester.
2. When that code is released, the tester regresses (tries to reproduce) the bug in the new release.
3a. If the bug is fixed, *then* status goes to 'closed'.
3b. If the bug is not fixed, *then* status goes back to 'open' and bug is assigned back to the developer.

(task,new) -> (task,open) -> (task,completed) -> (task,closed)


Yeah - and if there is disagreement or misunderstanding or whatever about what 'completed' really means/meant, then there might be an alternate path from 'completed' to 'open'.

Example:
I have a task assigned to me.
I complete what I think the task entails ("do X") and set it to 'completed' and assign it to whoever is managing that task.
Whoever is managing that task checks on task completion and says "no, that task also includes doing Y and Z, not just X" and sets it back to 'open' and assigns it back to me.

I suppose I'm thinking we need something like:

(bug,new) -> (bug, open) -> (bug,resolved) -> (bug,closed)
^ |
|- new build <-------------------

In that the the developer fixes bug, then the tester verifies
that the bug really is fixed.


Yeah, words exactly correct; flowchart not however.
A bug is only closed after the tester has regressed it against the new build in which it is allegedly fixed and found that it is in fact fixed.

In other words, resolved only goes to closed (or open) by way of regression, normally.

There are always a few exceptions now and again - mistakes in entry, buggy bugs that suddenly can't be reproduced, etc. They will get closed by admin or appropriate person on a case-by-case basis.

I guess all I'm asking is that there be a way to signal in the tracker

1) A bug is fixed, and verified, but there is no need to test this later.
2) A bug is fixed, verified, but needs to be part of later regression.




There does need to be a way (not necessarily in issue tracker)
for Joe Public to register a bug. Forcing users to log on
is a "bad thing" as most don't want to go that hassle. This
could mean that we never get to see a bug at all.


One option would be to set up an e-mail address for anonymous bug reports.
Then a tester can check the mail every so often, try and repro the alleged bugs, and if they actually are bugs the tester can enter then in the tracker.

IMO why bother? We don't want random bugs from random Joe Publics.

> They will be more trouble than they're worth.

Absolutly not. On numerious ocassions a member of the public has spotted something wrong with the pfaf site, and emailed me to report it.
Its the 1000 eyeballs theory of open source methodology. The more people
examining the code/data the better.

This is a community project; what we want is bugs from our community of users, who will be playing with/using PIW as we develop it and will not have an issue registering with the tracker so that they can contribute bugs. In fact it will be part of their 'membership' in or 'buy-in' to the project that they are registered.

Only problem is registration restricts entry. Restricted entry makes a smaller community, whereas we want as many people using the piw site as posible.

I definitely don't support anonymous users entering bugs directly into the issue tracker.

I'm fine with that. Maybe what we need is a user forum which allows
people to post bug reports etc.

It's a security risk, a spam-bug risk, and most simply an invitation to get tons of really crappy bugs that probably aren't even bugs clogging up the tracker, with no way to enact consequences on the offending users.

Also no way to assign it back to them for regression after a fix is made.


One last Q. What the difference between new and open?

Rich





Archive powered by MHonArc 2.6.24.

Top of Page