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