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: Tue, 17 May 2005 16:45:34 -1000 (HST)

Aloha,

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

We're having a furious agreement here...that's what I'm saying below...
When I do some non-ascii flow diagrams it will hopefully be much clearer
to all.

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

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

Any bug fixed and the fix verified will be set to closed - that takes care
of that one.

> 2) A bug is fixed, verified, but needs to be part of later regression.

Fixed and verified is closed, period - bug no longer exists.
So, nothing to regress.

This is not the same as what will be tested for on each build, such as the
initial 'sanity check' test and all the other normal testing we'll want to
do.

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

I agree with the 1000 eyeballs - but if they want to enter a bug in the
tracker, they will have to be willing to register. I am not aware of
appreciated open source projects having trouble with 'public' testers
registering.

> Only problem is registration restricts entry.

How? It's free and easy and takes a few minutes at most. If someone is
only willing to participate anonymously...why is that?

I think there's a reason Slashdot has the category 'Anonymous Coward' for
anonymous blog posts...

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

As long as someone is willing to sift through them, verify those that are
genuine, and put them into the tracker, fine by me.
Otherwise seems like a waste of time.

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

New means a tester has entered a bug, that's all, nothing else has
happened with it.
Open means it's been recognized as a legit issue of some sort and is in
progress in some way (assigned to developer, normally).
Currently the tracker changes New to Open automatically when the first
comment is entered. It can also be done manually of course.

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