pcplantdb

[Richard Morris <webmaster@pfaf.org>]

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