how is trac SUPPOSED to be used?
Stedwick
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.
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.
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?
Thanks!
Philip
www.readMedia.com -- Local Press Releases.
Noah Kantrowitz
>
> 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.
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
Iain Buchanan
> 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.
Jani Tiainen
> 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
Chad Emahizer
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
Chad Emahizer
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-...@googlegroups.com [mailto:trac-...@googlegroups.com] On
Behalf Of Stedwick
Sent: Tuesday, October 07, 2008 3:38 PM
To: Trac Users
Chad Emahizer
configurations of the trac.ini file and a trac.db file? Maybe it's as
simple as that. I would think some sort of "white paper" would be needed
(maybe documented in the wiki) that explains how the specific process the
specific configuration is supposed to work. Maybe a large(ish) percentage
of processes could be covered by a small(ish) number of specific
implementations.
I think it is akin to how Apache and mysql was for me when I was trying to
install a certain web-based bug tracking system for the first time. I
didn't know how to run a web server and deal with a db server. More
importantly, I didn't want to learn...had neither the time nor the desire.
So finding the prebuilt and configured Apache release XAMPP by Apache
Friends was the only thing that allowed me to move forward.
Is it as "simple" as defining and documenting a process, configuring it,
zipping the necessary pieces, and putting it up for distribution? Ok, not
so simple to define said process, but configuring Trac once the hard part is
done is relatively easy I think. It would be nice to have certain plugins
preinstalled too, though I'm sure there's issues with redistributing others'
plugins, even with the positive goal of more adoption of Trac. I've not
tinkered with dropping portions of a configured Trac system into an existing
Track install to see how it reacts...
This would allow the ability for Trac development to continue on the generic
path it is currently on, yet allow someone to pick a pre-setup configuration
that more closely fits the way they do business so they don't have to get
their hands dirty in the nitty-gritty details.
Chad
-----Original Message-----
From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] On
Behalf Of Noah Kantrowitz
Sent: Wednesday, October 08, 2008 3:20 AM
To: trac-...@googlegroups.com
Subject: [Trac] Re: how is trac SUPPOSED to be used?
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.
--Noah
Chad Emahizer
have worked...
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-...@googlegroups.com [mailto:trac-...@googlegroups.com] On
Behalf Of Stedwick
Sent: Tuesday, October 07, 2008 3:38 PM
To: Trac Users
Chad Emahizer
worked...
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 have the pretense
of planning), but it would likely be sufficient if 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-...@googlegroups.com [mailto:trac-...@googlegroups.com] On
Behalf Of Stedwick
Sent: Tuesday, October 07, 2008 3:38 PM
To: Trac Users
yoh...@gmail.com
>closed
if you are after something a little more "common" try the enterprise
workflow in the contrib directory.
that said, it sounds like your group is perfectly happy being stuck
with something that is not customizable (or easily customized). in
that case, you might consider something else, but with the caveat that
nobody gets to ask for customizations (maybe aside from themes/skins)
Trac is a bit of labor to get it tweaked to exactly what fits your
organization. The flip side, is, well, it's worth it because you CAN
if you're agile, you could look at agilo. there is a release
candidate that runs on 0.11 and looks very complete. Even this still
allows a ALOT of customization, which I find a good thing, but out of
the box, it's good to go.
in order to do your date searching you mentioned, you will need to
write sql. there are some examples around on how to get this, so you
really only need to find it and cut and paste into a query. (sorry I
don't have a link atm, but I found one a while back that finds when a
ticket TRANSITIONED to closed, which was perfect)
however, another option is to add the DateTime plugin, and add a
custom field to tickets which people are required to fill in with the
current date when they close a ticket. Or you use more milestones,
and assign ticket to the milestone for the last to weeks. if it's
closed, and milestone matches...etc. this would be more towards the
"sprint" model of scrum.
I will go back to say, I bet even with an out of the box solution,
your group will want SOME sort of customization, which might be
difficult if not impossible with other systems. (such as custom
workflows, particularly to the level Trac has them.) The subversion
hooks are really nice as well. the ability to update a ticket when
you check in a file, just via the comments, adds to productivity and
traceability. This again, is something you need to enable/configure,
since trac doesn't force you to even use source control at all. Still
sounds like the best route for you personally might be somehting else
that is out of the box, and inflexible. and then they are just stuck
with it.
Dimitri Maziuk
> 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
Robert C Corsaro
Man, you're not supposed to say stuff like that out loud. That's why
everyone hates us!
Dimitri Maziuk
>
> Man, you're not supposed to say stuff like that out loud. That's why
> everyone hates us!
Not everyone, just the second bunch -- us arrogant elitists snobs
generally don't have a problem with the idea that trac is not right for
everyone. It's the other crowd that tends to fervently believe what's
good enough for them must be good enough for jesus and the rest of human
species -- and you better like it!
Dima
Jeff Hammel
>
> 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
Jeff Hammel
This IMHO is the right direction to go: keep trac generic but allow people ways of easily distributing customized "packages" that can be used to create trac instances. To this end, I've been working on a program called TracLegos (http://trac-hacks.org/wiki/TracLegosScript) that will do just that -- allow packaging and distribution of trac.ini files and requirements files for plugins. The program is still in its infancy, but I'd love feedback on whether this idea is useful to people. It was motivated by this concern coming up again and again.
(Nor is TracLegos the only software that does this. TracForge also supports this sort of thing)
Hope this is useful, at least in the abstract. Feel free to ticket and ask questions, as I'm very interested in people using this plugin if it does help with this problem.
Jeff Hammel
The Open Planning Project
http://topp.openplans.org
IRC: jhammel, k0s
> -----Original Message-----
Erik Bray
> 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.
Perhaps that's it. I think "the Apple way" is awful, and nowhere near
what I want. The very *least* iTunes could do is let me enter a
format string for how I want files named when I rip a CD, but it can't
even do that.
But that aside, I'm not sure how else to understand your dilemma with
Trac. If you want Trac to dictate how you do your work you could try
one of the more structured derivatives like Agilo. But it really
depends on what your development process is. You said it
yourself--Trac is meant to stay out of the way and mostly only do what
you want it to do. If you don't even know what you want to do with
it, I can understand how you're stuck.
Erik Bray
In fairness to Bill Gates, I've found most Microsoft software much
more willing to be told to behave the way I want it to behave than
Apple software. That's not to say that the MS stuff doesn't have its
own set of usability problems--it's usually clunkier and more bloated.
I just usually feel far more boxed in when I'm using Apple software.
But that's an off-topic discussion so I'll leave it at that.
Now Trac, on the other hand, gives me a great deal of freedom. And of
course as with any open source software (especially with a less
restrictive license) we are free to modify it if there's something
specific we need to change about it. And the fact that Trac imposes
very little process to begin with, and is very modular, it's a lot
easier to modify without stepping on any toes.