On Wed, Oct 08, 2008 at 08:21:42AM -0400, Chad Emahizer wrote: > > I broke this out into a separate email because otherwise it would be one > huge email that rambled, which I have a tendency to do anyway... > > I might try to do this specific example with milestones. Define a Trac > "milestone" as a merge point in the software, like the one you had two weeks > ago. Assign the tickets to the "next" milestone in line, and when a merge > point happens, create another milestone and send all unresolved tickets to > that new milestone. At any given time you can quickly see what tickets have > been closed by milestone. I wouldn't exactly say that's how I would use the > milestone feature in a perfect world (I like to at least of the pretense of > planning), but it would likely work used that way.
<snip/> As far as how trac is "supposed" to be use with respect to those that want a program to enforce methodology versus a program to support multiple methodologies, it seems to me that using milestones is the trac way of doing what is desired here. Marking things as milestones is probably a good practice anyway for this case as it enables a project manager to think of a group of tickets as a concerted effort instead of the more ad hoc date query. IMHO, Jeff Hammel The Open Planning Project http://topp.openplans.org IRC: jhammel, k0s > > Another approach could be to use the version field. Make set the version > field up to have whatever you want to call the merge points, like the one > you had two weeks ago. Code name them. Refer to a build number. Use a > targeted merge date...whatever. As you close tickets, set the version to > the merge point next in line when it was closed. This isn't exactly right > either, as "Version" would typically (I think) be used to designate what > software version the issue was found in, not the version the issue would be > fixed in. However, that being said, you are free to use it how you like and > define. > > A third could be a custom field. Make a custom field for whatever you want > to call the merge points as said above. As you close tickets, set the field > to the name of the merge point next in line when it was closed. This > approach is a little harder because querying based on custom fields is > tough, or so I have read...I've not done it. I'm fairly confident, as you > pointed out, that if I decided I needed to search custom fields for > something I could find adequate documentation to help me do so, I've just > not had the need. > > Hope I was at least a little helpful. > > Chad > > -----Original Message----- > From: trac-users@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Stedwick > Sent: Tuesday, October 07, 2008 3:38 PM > To: Trac Users > Subject: [Trac] how is trac SUPPOSED to be used? > > > For example, my boss recently asked me what changes were going to be > moved into the trunk since the last merge two weeks ago, and I thought > to myself, "Oh, I'll just do a search for all the bugs that I fixed in > the past two weeks," but, amazingly, I CAN'T DO THAT. Even using > "custom query" there is no field that allows you to query based on > time. And I certainly don't want to start writing SQL. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
