Mailing List Archive: Trac: Users

Re: how is trac SUPPOSED to be used?

Index | Next | Previous | View Threaded

noah at coderanger

Oct 8, 2008, 12:19 AM

Post #1 of 7 (199 views)
Permalink

Re: how is trac SUPPOSED to be used?

On Oct 7, 2008, at 12:37 PM, Stedwick wrote:

>
> This is going to sound like a rather vague question, but how is trac
> SUPPOSED to be used?
>
> The reason I ask is because we use trac at my company, but we are
> thinking of switching to something else. Nobody at my company seems to
> like it. I just came on board a month ago, and I've never used trac,
> and it's kind of been placed upon me to research alternatives, but I
> figure that trac is used everywhere so it's got to be good and we are
> probably just using it wrong.
>
> However, a month has gone by, and I really can't figure trac out. It
> doesn't seem to work, or do anything at all, for that matter. I'm kind
> of stymied. I've heard this from other people as well; trac is just
> baffling and weird. I think I've read that track is supposed to "adapt
> to YOUR workflow, and work the way YOU want it to", but it seems to me
> that it has no workflow at all.

This is correct, one of the central design tenets of Trac is that it
enforces as little process on you as possible. This does seem to
backfire sometimes, as there is a large segment of the userbase that
would like more structure than that. If you have a suggestion on how
to resolve this, please let us know, it is frequently debated but
people rarely seem to come up with anything solid.

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

Time-based queries were indeed one of the major deficienes of the
query system vs. reports. I believe this feature has been checked in
to trunk, and so will be part of 0.12 when it is released. In the mean
time, yes you have to write SQL. The query system is no where near a
full replacement for reports, which is why despite their ugliness
reports have not been removed yet.

> I read over the documentation, and it does a good job of explaining
> WHAT things do, but I can't find anywhere that explains what it was
> DESIGNED to do. How were tickets DESIGNED to be used, if they weren't
> designed to be used based on date? To me, the date seems the most
> obvious thing to track bugs by, other than perhaps by severity. The
> date reported, the date fixed, the date released.
>
> I'm wondering if it's a philosophical conflict. The people at my
> company (myself included) like opinionated software. It's like iTunes.
> Everybody hates iTunes because they can't manage their music in their
> own unbelievably specific manner. However, if you use iTunes as it was
> DESIGNED to be used, you will discover that it's an amazing, excellent
> piece of software. I can't imagine managing my music any other way. It
> just works so well. You just have to get by the fact that you have to
> do things "the Apple way". Believe it or not, the Apple way is usually
> pretty good.
>
> I'm concerned that the trac way is... well, I don't think it even has
> a way. Does it? I can go to the subversion documentation, or the git
> documentation, and it will tell me EXACTLY how I'm supposed to manage
> my source code, how my teams are supposed to work together, how
> merging is supposed to work, what the workflow is, et cetera. There
> are a couple of options of course, but at least they are well
> documented options.
>
> Anyway, sorry for the strange question. Can anybody explain to me how
> a usual "trac workflow" is supposed to look? Or a good website that
> goes over how people generally use trac?

You can look at the TracUsers page to see other people using Trac.
Some major places I know you can look include Trac itself,
dev.laptop.org, developer.pidgin.im, trac.adiumx.com. Beyond that you
will need to sit down and figure out what works best for you and your
team.

--Noah

--~--~---------~--~----~------------~-------~--~----~
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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

iain at pcorp

Oct 8, 2008, 12:27 AM

Post #2 of 7 (189 views)
Permalink

Re: how is trac SUPPOSED to be used? [In reply to]

Noah Kantrowitz wrote:
> On Oct 7, 2008, at 12:37 PM, Stedwick wrote:
>
>> This is going to sound like a rather vague question, but how is trac
>> SUPPOSED to be used?

[snip]

For a more structured, restricted, but still powerful way of using Trac
to manage bugs as well as handle project management, have a look at
http://www.agile42.com/ which implements Agile Development using a
customised version of Trac (based on 0.9.x)

If you don't know much about Agile development, this will probably
confuse you more than help, so it's worth reading some of their links
("Scrum in a nutshell", etc) or
http://en.wikipedia.org/wiki/Agile_software_development or whatever else
google throws at you.

HTH,
--
Iain Buchanan <iain at pcorp dot com dot au>

Phasers locked on target, Captain.

--~--~---------~--~----~------------~-------~--~----~
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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Attachments:

iain.vcf (0.15 KB)

redetin at gmail

Oct 8, 2008, 12:42 AM

Post #3 of 7 (191 views)
Permalink

Re: how is trac SUPPOSED to be used? [In reply to]

Noah Kantrowitz kirjoitti:
> On Oct 7, 2008, at 12:37 PM, Stedwick wrote:
>
>> This is going to sound like a rather vague question, but how is trac
>> SUPPOSED to be used?
>>
>> The reason I ask is because we use trac at my company, but we are
>> thinking of switching to something else. Nobody at my company seems to
>> like it. I just came on board a month ago, and I've never used trac,
>> and it's kind of been placed upon me to research alternatives, but I
>> figure that trac is used everywhere so it's got to be good and we are
>> probably just using it wrong.
>>
>> However, a month has gone by, and I really can't figure trac out. It
>> doesn't seem to work, or do anything at all, for that matter. I'm kind
>> of stymied. I've heard this from other people as well; trac is just
>> baffling and weird. I think I've read that track is supposed to "adapt
>> to YOUR workflow, and work the way YOU want it to", but it seems to me
>> that it has no workflow at all.
>
> This is correct, one of the central design tenets of Trac is that it
> enforces as little process on you as possible. This does seem to
> backfire sometimes, as there is a large segment of the userbase that
> would like more structure than that. If you have a suggestion on how
> to resolve this, please let us know, it is frequently debated but
> people rarely seem to come up with anything solid.

This is something that is Trac power and weakness. Most Trac like
software establish some sort of workflow that you must follow, Trac
instead is a liberate in that matter.

One problem with corporate users often seek ready to use solutions that
have quite straight forward workflows and ways to use software.

With Subversion you can do pretty much everything that you do with
normal files, svnbook just represent one "trunk, tags and branches" way
to work, but people seem to use that quite often.

http://trac.edgewall.org/wiki/TracBooks contains one book to read about
"realworld" usage. I haven't read it though so hard to tell is it any good.

--
Jani Tiainen

"Tein sein mihin n�ill� lahjoilla pystyin.
Tein sen, en yht��n enemp��." - Martti Servo & Napander

--~--~---------~--~----~------------~-------~--~----~
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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

cemahizer at inspecttech

Oct 8, 2008, 4:53 AM

Post #4 of 7 (181 views)
Permalink

Re: how is trac SUPPOSED to be used? [In reply to]

I think I might be restating a bit here from what others have already said,
but Trac does (or can do) what you want it to do. It is flexible and
doesn't force its own "business logic" on its users. It basically has to be
like that, or it will be targeting only a small portion of the population
regardless of whichever specific implementation it would choose to
implement.

A problem with that approach is that not only do you have to learn a new
tool, but you also have to understand the processes your company has in
place and then determine ways to configure/utilize Trac to fit in with those
processes. In some cases you might have to recognize that you don't have
processes so you'll have to invent them, then figure out what you want Trac
to do, then figure out how to make Trac do that...quite daunting in some
cases. The good news is that Trac will allow you to do those things.
Unfortunately that means there's some work involved. It is not something
that you can unzip and put in a directory and have it run tailored to your
specific business logic right out of the box.

So, maybe the question shouldn't be "How is Trac supposed to be used?".
Maybe it should be "What are the processes for my company, and how can I
tailor Trac to enforce those processes and make them easier to do?"

Chad

-----Original Message-----
From: trac-users[at]googlegroups.com [mailto:trac-users[at]googlegroups.com] On
Behalf Of Stedwick
Sent: Tuesday, October 07, 2008 3:38 PM
To: Trac Users
Subject: [Trac] how is trac SUPPOSED to be used?

This is going to sound like a rather vague question, but how is trac
SUPPOSED to be used?

--~--~---------~--~----~------------~-------~--~----~
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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

cemahizer at inspecttech

Oct 8, 2008, 5:21 AM

Post #5 of 7 (182 views)
Permalink

Re: how is trac SUPPOSED to be used? [In reply to]

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.

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[at]googlegroups.com [mailto:trac-users[at]googlegroups.com] 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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

dmaziuk at bmrb

Oct 8, 2008, 7:33 AM

Post #6 of 7 (177 views)
Permalink

Re: how is trac SUPPOSED to be used? [In reply to]

Chad Emahizer wrote:
> I think I might be restating a bit here from what others have already said,
> but Trac does (or can do) what you want it to do. It is flexible and
> doesn't force its own "business logic" on its users. It basically has to be
> like that, or it will be targeting only a small portion of the population
> regardless of whichever specific implementation it would choose to
> implement.
>
> A problem with that approach is that not only do you have to learn a new
> tool, but you also have to understand the processes your company has in
> place and then determine ways to configure/utilize Trac to fit in with those
> processes.
...
> So, maybe the question shouldn't be "How is Trac supposed to be used?".
> Maybe it should be "What are the processes for my company, and how can I
> tailor Trac to enforce those processes and make them easier to do?"

There are 2 kinds of users: those who want to tweak software to do what
they want, and those who're happy to click on a button and let the
software take them to wherever Bill Jobs (aka Steve Gates) thinks they
want to go. Those in the second category should probably not use trac,
linux, or any "programming languages" other than flash.

Dima

--~--~---------~--~----~------------~-------~--~----~
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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

jhammel at openplans

Oct 8, 2008, 8:13 AM

Post #7 of 7 (175 views)
Permalink

Re: how is trac SUPPOSED to be used? [In reply to]

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[at]googlegroups.com [mailto:trac-users[at]googlegroups.com] 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[at]googlegroups.com
To unsubscribe from this group, send email to trac-users+unsubscribe[at]googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com