Skip to Content.
Sympa Menu

pcplantdb - [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: [pcplantdb] Issue tracker clarifications
  • Date: Sun, 15 May 2005 21:09:57 +0000

Aloha,

Whats the difference between closed, resolved and compleated?

Resolved means the developer claims to have fixed the bug.

Completed means the person(s) a task is assigned to claim(s) to have completed the task.

Closed means that for either of the above cases, some person responsible for verifying such things has verified that the bug really is fixed or the task really is completed.

In the case of a bug, the tester verifies (or not) the developer's claim of a fix.

In the case of a task, there would ideally be verification of task completion by some person managing the task - this is not well defined at present in our situation.

Is there a way to mark a resolved issue as being part of the
on going regression test.

A bug will be set to resolved when a developer makes a change intended to fix the bug in code that will be part of the next release.

In other words, any bug with status 'resolved' needs to be regressed against the next build.

There seem to be some things in the tracker
which we don't need to revisited, and other which do need checking
with each new release.

For bugs:
A bug fix will either work, and the bug then be marked 'closed', and thus not revisited...
...or a bug fix will not work, and the bug then be set back to 'open' status, and then be revisited again (regressed) in some later build.

A given task may or may not be related to a particular build, so revisiting 'task' issues will probably vary wildly.

It seems like the issue tracker is being used for some seperate things:
1) regression testing system
2) bug reporting

These two are part of the same system. Bug reporting and regression testing are mutually interlinked:

A bug is reported and gets set to 'open' status.
A developer makes a fix and sets it to 'resolved' status.
A tester regresses (tries to reproduce) the allegedly 'resolved' bug in the new build and sets it to 'closed' (if bug is gone) or 'open' (if bug is still present).

3) project managment, i.e. scheduling tasks to be done

Yes, this would be an issue of type 'task'.

4) feature requesting

This would be an issue of type 'suggestion'.

I'm wondering if its posible to split these up. May be this is what
the Task tag is for.

Yep, exactly. To see all still-in-progress tasks, do a search for all issues of type 'task' and status 'open'.

To see all bugs that need to be regressed in a new build, search for all issues of type 'bug' and status 'resolved'

...and so on...the ability to name and save your most common searches (queries) as links in your sidebar is one of the very nice features of Roundup.

I guess the process might be
a) A "feature request" is added.
b) we discuss whether or not we want to implement it and
what priority it has.
c) The "feature request" is promoted to a "task". I.e something to be done.
c1) Specification updated.
d1) Task is compleated.
d2) Tests developed to check that the feature works as intended.

Yep, that would be a process for dealing with issues of type 'suggestion'.
If it's not a current priority it can remain as a 'suggestion' until whenever we periodically revisit pending suggestions.

e) regression happens.

Regression testing wouldn't apply in this case.

It would apply if the feature is broken or partly works, resulting in a bug or bugs being generated, resulting in a fix or fixes being done, which fixes would then be regressed in the next build to see if the feature was now working, or was less broken.

Order of d1/d2 could be different. As a design methodology, there is a
lot of people into test first systems. I.e. write the test first then write the code and check if it passes the test. (Never done this).

I can honestly say that I have never seen this done in a commercial production environment...great methodology idea though... ;-)

I guess a home page for the tracker is needed. IE a page where
new users first come to the tracker and public users can either
add a "feature request" or a "bug", but not a "task" or a "regression test".

Not sure what you mean by 'public users'.
Anonymous users can only view existing issues - to create an issue of any type, one will have to register as a named user.
User name of issue creator is automatically logged in the issue history.
So if anyone abuses their registration by creating inappropriate issues, that user will suffer the consequences...

I think I'd recomend changing the "suggestion" task to "feature request", its a name which has more resonance for me.

I just want to keep it short... :-)
I see 'feature request' as a subset of 'suggestion' - suggestions might include things besides program features.

Don't really know what "Know issue" is about.

Known issue is shorthand for "we know about this and that's how it is/works, love it or leave it, don't expect us to do anything about this."

Sometimes it would be applied to bugs or suggestions people submit that we don't think are bugs or valid suggestions.

Sometimes it is applied to valid bugs that cannot reasonably be 'fixed' for whatever reason (system constraints, design flaws, whatever).

An alternate phrase some systems use is 'as designed' - I put 'known issue' because it seems more open and less arrogant...

Thanks for all these questions...I can use my above responses almost directly in some of the docs I need to put together. Keep 'em coming!

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