Slashdot Mirror

I recently switched my internal development from CVS to Subversion, and use trac (there site seems to be down right now) as a front end to it all. Trac is a web based interface (written in python) that is a combination wiki, bug tracker, source viewer, changelog and milestone tracker. It has some amazingly cool features, like the ability to put wiki markup anywhere.

Using a wiki for documenting code is somewhat handy, but what's even better is the wiki extensions trac adds. You can type "This is related to bug #236" and it will make it a link to that bug. The cool part is, you can do that anywhere -- such as an svn commit message. (There's also ways to link to milestones, revision numbers, etc)

I originally switched to subversion for the big features - the ability to move files/directories, and the simple (compared to cvs) tagging/branching support. Trac just made it that much better.

although it's based upon SVN (which I know has its downsides), I've found trac to be the best package to work with in terms of version control and project managment.

perhaps our model of a versioning system is outdated just because everyone keeps thinking of CVS. maybe we really just need a graphical set of tools to manage source.

there are definite usability advantages to using a visual/sptaial interface for managing large quantities of information (such as the linux source tree).

and yes, I am a mac user. I also run linux. I also see the necessity of the command prompt and use it for scripting in addition to applescript (both of which are soon going to become unnecessary. . Of course, for everyday tasks, when asked to choose between the Aqua GUI and the commandline, one would be a fool to pick the commandline. The linux GUI paradigm is absurd -- X is basically a wrapper for the command line -- most GUIs and programs are based around the limitations of their command-line equivalents. It just pains me to see so much effort being wasted on open source development due to poor project organization.

If you can picture the entire source tree and kernel structure in your head, great, there are about 9 other people in the world like you. If not, then kernel development will slow to a crawl. Granted, any usability expert will argue that in order to be functional, the developer should not HAVE to know the inner workings to contribute, but still.

You really need just three things, and in my experience, nobody bothers to even go this far.

What might help is a project management infrastructure to assist in doing these things.

For design documentation and documentation in general you need a rudimentary content management system. It can be as simple as document repository under version control.

For e-mails to track changes and record on-going discussions and debate, use a change management system like Request Tracker or a threaded discussion group program with email notification.

Gforge, Tudos and trac are complete systems for managing development.

Having project management infrastructure in place at all times means that you can turn anything that requires more then, say, one person working two days, into a formal project with minimal overhead.

These systems reduce the number of face-to-face meetings that eat into development time and at the same time improve communication. The result is that there can be a measurable improvement in even the smallest project. Perhaps, especially in the smallest projects.

Try TRAC: http://projects.edgewall.com/trac.

Does a fair job of integrating Subversion, wiki, and ticket/bugtrack tool.

I have been using Trac for a little over half a year. Trac provides a combination of wiki + ticketing system (bug/issue tracking) + Subversion integration for source. Project Roadmap and Milestones are particularly helpful.

Check it out at http://projects.edgewall.com/trac

Subversion definately can be a pain to setup, but I've found it to be worth the effort.

One tool that gives you an excellent and basically unrivaled look into your code with subversion is trac.

Definately worth checking out for any subversion users.

I may have mentioned it before, but I just started using trac as a sort of sourceforge sort of intranet thing. I was only really looking for a cgi gateway to subversion too. It's a bitch to install, but worth it.

Get the latest straight out of version control and use it as tracd (even though it's marked as experimental). Way easier than running it through apache.

Dave

Since everyone seems to have given more or less commercial-feeling suggestions, try Trac. It's a decent project-management system with a Wiki, implemented in Python running off CGI. It's mainly intended for actual PMS, but seems to work well for a support job too.

I recently completed reading it from cover to cover, and while I didn't yet even code the examples myself (I plan to do that on my second read), every chapter felt like a series of revelations.

Highly recommended. Combine that with other books (Dive into Python looks very nice) and a few extra resources, and you and/or your students should be positively churning out code. A couple of nice ones:

Python Sidebar (originally for Mozilla, but works on at least Opera as well)
Python 2.3 Quick Reference (utterly brilliant)

The correct URL for Trac is http://www.edgewall.com/products/trac/ sorry.

1. A dedicated QA staff. You should have as many testers as you have developers.
2. Tools for the QA staff to create their own automation. They don't like doing manual testing much, either, so they'll have incentive to use the tools. :-) I'll talk about the tools we use in a bit.
3. Training for the QA staff on the tools. Hire QA people capable of at least a little shell programming. And the tools they use should be not much harder than writing shell scripts.
4. A good SCM (source code management) system that provides atomic commits, so that when you fix a bug, you can tell your testers exactly what revision number it's fixed in, and they can get exactly that revision verify it in the same system you had when you fixed it.
5. A bug tracker. It doesn't have to integrate with the SCM, but if it doesn't, you should make it a hard policy that your commit log messages should say what bug number they are a fix for, and when you resolve a bug, you must say what revision the fix went into. I can't even estimate how much time this policy saves.
6. Automated rebuilds of every revision of the software. Spend a lot of time on this, it's key. It lets your testers test things the minute you fix them. That means, if you failed to fix it correctly, you'll find out SOON while the fix is still fresh in your mind, and you'll save even more time by not having to get back into the mindset of that bug. You will need special software to do it, so read on.

1. For us, our project has had 1-2 developers working full time (me, plus one additional deveoper at various times). We've also had 1-2 testers working full time. That sounds like a small project, but after two years of dev it is a lot of code, and all that code needs testing. The fulltime test staff available right from the start was absolutely not money wasted.
2. The development is done in Python, with Twisted, and so we used a combination of unit tests written by the developers and black box tests written by the testers. Because our app is primarily web, I developed my own web test system (having found no others that were suitable for use by non-programmers). This system is PBP, which is a shell-like scriptable web browser.
3. Our main tester had a little bit of C in school (she actually had forgotten most of it ;-) and a little bit of unix command line experience. This was more than enough to be able to design and build tests with PBP. Then I spent about one full day showing her how to use it and brainstorming testmaking strategies with her.
4. Subversion.
5. We've been successful with Bugzilla. If I had to start over, I probably would have used Trac, with which I've had good experiences on other projects.
6. I built a completely automatic build system using Buildbot to trigger the builds after each commit and A-A-P to script the build process.

It's written as a Python CGI app, which uses ClearSilver for templating and the Subversion python bindings to surf the repository.

Take a look at Trac, by Edgewall. Trac is a well-done integration of a project wiki, an issue tracker, and a repository viewer, specifically for Subversion. It works well for me, so I thought I'd plug it a bit.

Regarding wiki markup, how much markup do you really need? Developers and DBAs shouldn't have an issue learning it, and designers and customers shouldn't need to learn it. They can write plain text without losing much. The point of a wiki is to facilitate communication, not to waste time with excess markup.

Your "presentation quality" documentation probably shouldn't be written on a wiki, anyway. The content, maybe, but not the actual, end-product document. With Subversion as a dependency, you already have a source repository, so use it. Stick your docs there, and let folks make reference to them in the wiki and the issue tracker. The combination of functions, wiki, tracker and repository, is much stronger than each separately.

It's a minimalistic issue tracker for software projects based on Wiki and Subversion (with later support for Arch and CVS planned), written in python.

Trac has browsing of Subversion repositories, viewing diffs/changesets and allows judicious hyperlinking between bug reports, commit-messages and

If you've seen cvstrac or viewcvs, you'll be familiar with the concept.

Check it out at http://trac.edgewall.com/

It's a minimalistic issue tracker for software projects based on Wiki and Subversion (with later support for Arch and CVS planned), written in python.

Trac has browsing of Subversion repositories, viewing diffs/changesets and allows judicious hyperlinking between bug reports, commit-messages and

If you've seen cvstrac or viewcvs, you'll be familiar with the concept.

Check it out at http://trac.edgewall.com/

If you like ViewCVS, you might want be interested in Trac, a combined bug tracker and wiki that uses Subversion. It's pretty neat.