Mailing List Archive

No one responded to my email, so I think that means everyone does not
have any problems with the current implementation of the Trac tickets.
I can see where the simplified model may be easier to use with small
projects, but as projects grow, this seems like it could be
insufficient. Subversion uses this state model for their issue
tracking: http://subversion.tigris.org/scdocs/issue_lifecycle.html



So my next question would be: How hard would it be to add more states to
the ticket status?



Thanks! Kevin



-----Original Message-----
From: trac-bounces@bobcat.edgewall.com
[mailto:trac-bounces@bobcat.edgewall.com] On Behalf Of Lee, Kevin
Sent: Friday, May 14, 2004 11:49 AM
To: trac@bobcat.edgewall.com
Subject: [Trac] Tickets Usage Question



Hi,



I'm trying to figure out how we can use Trac Tickets for our projects.
I'm not sure how to model the state that a bug has been fixed and is
ready for verification by QA. A bug is typically not considered
resolved until it has been included in a build and verified by QA.



Also, I'm used to having a way to know when a fix for a bug is ready to
be built (ie. It has been committed). This is not as important as the
ready for QA state.



I'm used to the following use case:


TRAC

1) QA gets a build (labeled BUILD_A) and starts testing

2) QA finds a bug and files a bug against build BUILD_A New
Ticket

3) Developer investigates bug


a. Not a problem - user error
Resolved - invalid

b. Works for me
Resolved - WorksForMe

c. Finds issue
Accepted

4) Developer releases fix for bug
???? - ready to build - assign to the build mgr

5) Bug fix goes into a new build - BUILD_B
???? - ready to verify - assign to the tester

6) QA gets build BUILD_B and retests bug against fix


7) Bug is either

a. Fixed
Resolved - fixed

b. Needs more fixing
Reopened ?



Is there a way in the current Trac setup to allow this use case? How
are other people using Trac?



Also, I see a button for accepting a ticket, but whenever I reassign a
ticket to someone, it automatically gets set to accepted. Is there a
config somewhere that I need to set to allow the assigned person to
accept a ticket?



I'm just a beginner with Trac. Is it easy to modify the configuration
of the web pages and/or the database to add this kind of functionality?



Thanks! Kevin Lee

kdlee@qualcomm.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /archive/trac/attachments/20040528/e303ee93/attachment.xhtml

I looked into this recently, and the ticket state workflow is coded into the
Ticket.py module. I.e., you would be changing the workflow of the entire
ticket module.

I would like to suggest that resolutions be something that is configurable,
though.

I have also gotten a request that the 'assign to:' field be a dropdown of
valid assignees.


Cheers,

:D

--------------------------------------------------------------------
Daragh Fitzpatrick Daragh@UChicago.edu (773) 702-8976

Solutions Architect NSIT Administrative Systems
Renewal Projects and Architecture University of Chicago
--------------------------------------------------------------------



_____

From: trac-bounces@bobcat.edgewall.com
[mailto:trac-bounces@bobcat.edgewall.com] On Behalf Of Lee, Kevin
Sent: Friday, May 28, 2004 12:38 PM
To: trac@bobcat.edgewall.com
Subject: RE: [Trac] Tickets Usage Question



No one responded to my email, so I think that means everyone does not have
any problems with the current implementation of the Trac tickets. I can see
where the simplified model may be easier to use with small projects, but as
projects grow, this seems like it could be insufficient. Subversion uses
this state model for their issue tracking:
http://subversion.tigris.org/scdocs/issue_lifecycle.html



So my next question would be: How hard would it be to add more states to the
ticket status?



Thanks! Kevin



-----Original Message-----
From: trac-bounces@bobcat.edgewall.com
[mailto:trac-bounces@bobcat.edgewall.com] On Behalf Of Lee, Kevin
Sent: Friday, May 14, 2004 11:49 AM
To: trac@bobcat.edgewall.com
Subject: [Trac] Tickets Usage Question



Hi,



I'm trying to figure out how we can use Trac Tickets for our projects. I'm
not sure how to model the state that a bug has been fixed and is ready for
verification by QA. A bug is typically not considered resolved until it
has been included in a build and verified by QA.



Also, I'm used to having a way to know when a fix for a bug is ready to be
built (ie. It has been committed). This is not as important as the ready
for QA state.



I'm used to the following use case:


TRAC

1) QA gets a build (labeled BUILD_A) and starts testing

2) QA finds a bug and files a bug against build BUILD_A New
Ticket

3) Developer investigates bug


a. Not a problem - user error
Resolved - invalid

b. Works for me
Resolved - WorksForMe

c. Finds issue
Accepted

4) Developer releases fix for bug
???? - ready to build - assign to the build mgr

5) Bug fix goes into a new build - BUILD_B
???? - ready to verify - assign to the tester

6) QA gets build BUILD_B and retests bug against fix


7) Bug is either

a. Fixed
Resolved - fixed

b. Needs more fixing
Reopened ?



Is there a way in the current Trac setup to allow this use case? How are
other people using Trac?



Also, I see a button for accepting a ticket, but whenever I reassign a
ticket to someone, it automatically gets set to accepted. Is there a config
somewhere that I need to set to allow the assigned person to accept a
ticket?



I'm just a beginner with Trac. Is it easy to modify the configuration of
the web pages and/or the database to add this kind of functionality?



Thanks! Kevin Lee

kdlee@qualcomm.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: /archive/trac/attachments/20040528/6e7bf117/attachment.xhtml