Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] Issue tracker clarifications

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: John Schinnerer <john@eco-living.net>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] Issue tracker clarifications
  • Date: Mon, 16 May 2005 20:49:22 +0000

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 <--

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.

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.

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.

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

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.

cheers
John S.



--

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Whole Systems Design Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net




Archive powered by MHonArc 2.6.24.

Top of Page