Slashdot Mirror

I liked Trac a lot... it was easier than Trac.

Is this some sort of "to prove a problem is NP-hard you must show that it is in NP and harder than all problems in NP" sort of thing?

I liked Trac a lot. It integrated Wiki, ticketing and Code repository information all in one and it was easier than Trac. However, it is not new or cool so developers don't think it was hip and always looking at something else.

If you can afford it, Jira and WIki from Atlassian (Confluence) are the best out there. If not, i would go with Redmine or Trello. You should also give asana a try. Here's a list that will guide you through what's out there: Freedcamp - Free - https://freedcamp.com/ - Online, doesn't log time directly on the task Velocity - Free and Paid - http://velocity.pm/ (Online) Time Tracking Brigthpod - Free (2 Projects) Paid - http://www.brightpod.com/ - Specify tasks, log work Asana - Free and Paid - https://asana.com/ (Online) - Doesn't log work Moovia - Free (2 members) and Paid - https://site.moovia.com/ (Online) Time tracking, Does not specify tasks Producteev - Free and Paid - https://www.producteev.com/ - Online, Does not specify tasks, doesn't log work Stepsie - Free - http://www.stepsie.com/ - Online, Does not specify tasks, doesn't log work Trello - Free - https://trello.com/ **** SELF HOST Redmine - Free - http://www.redmine.org/ Projects, wiki, issues Chili Project - Fork of Redmine Basecamp - close source - user friendly Open atrium (drupal) - not good issue tracking Collabtive - http://collabtive.o-dyn.de/ Kforge - https://pypi.python.org/pypi/k... ClockingIT - http://wiki.clockingit.com/ Assembla (SaaS Agile) Harvest (SaaS User Friendly) FreshBooks (SaaS) - Not open source - Time tracking invoicing Project Pier - Free - http://www.projectpier.org/ Trac - Free - http://trac.edgewall.org/ 2 plan - Free - http://2-plan.com/ MyCollab - Free - http://community.mycollab.com/... (Self hosted) Manage Yor Team - http://www.manageyourteam.net/ (Self hostes) Kanboard - Free - http://kanboard.net/ (light and self hosted) ProjecQtor - Free - http://www.projeqtor.org/ Task Coach - Free - http://taskcoach.org/ Task Juggler - Free - http://www.taskjuggler.org/ DotProject - Free - http://www.dotproject.net/ Project.net - Free - http://sourceforge.net/project... GanttProject (like MS Project) - Free - http://www.ganttproject.biz/ OpenWorkBench - Free - http://sourceforge.net/project... Codendi - Paid - http://www.codendi.com/ Egroupware 2014 - Paid - http://www.egroupware.org/star... - Atlassian Confluence and Jira - Trial and Paid Britix24 - Trial and Paid - http://www.bitrix24.com/ ProofHub - Trial and Paid - https://www.proofhub.com/ iCoordinator - Paid - http://www.icoordinator.com/en... FengOffice (like MS Project) - Trial and Paid - http://www.fengoffice.com/web/ Bugzilla - Bug tracking Mantis - Bug tracking *** Task Management Task Freak! - http://www.taskfreak.com/

I actually just implemented Trac at the company I am with. They were in a similar state for their issue tracking (mouth, emails, sticky note, short bursts of development with potentially very long intervals between software releases). I did a little research and ended up with Trac http://trac.edgewall.org/ It comes with a wiki, issue tracking, integrated source control (if you want it), easy searching/reports, plugins, SVN plugin, and it's open source. It is a web-based system so keep that in mind.

Installation was easy as well. You can set up yourself (perl, apache, mysql, etc.) Or you can use Bitnami to install a fresh instance https://bitnami.com/stack/trac... there is plenty of documentation to get an instance installed and configured fairly easily. For non-techies the Bitnami installation is huge because "out of the box" it works fairly well. Configuring will take a little know how but once that is done it's smooth sailing.

We just released it to a wider audience of our customers and the feedback has been well received. It took a little time for me to setup but within a few days it was up and running behind SSL and authenticated to our active directory with LDAP. Anyone on our network can easily log in and the permissions are set up as a per project basis (each user is assigned to a project group that can view/edit wiki,tickets of their associated project group).

It has only been a short time since we released it so there still might be some growing pains but it so far has help us get away from change requests in word documents and email.

Funny enough, I was about to ask /. the same question months ago before I landed on Trac. Hope this helps. Good luck!

Perhaps a new paradigm is needed; hosting within Tor but on servers the US gov has difficulty getting to, and a cold money trail. The "important" people in the network would need anonymity and would also need to not make money as admins or VIPs. Instead, they'd collect their profit as minor users (with different accounts) and keep most of their money within the system (e.g. free drugs). Real profits would go to charities (e.g. the EFF accepts bitcoin donations), ensuring that there is no usable money trail (obviously, the EFF would not back this kind of work).

Atop that, the new system could be better distributed (decentralized) and perhaps even free software (self-hosted via Trac or whatever) to follow the cryptographer philosophy of more eyes (reviewers) ensuring more security.

Of course, this assumes the Silk Road community has selfless idealists willing to coordinate this...

see here
and here.

I don't understand why nobody mentioned Trac yet.

Depending on your configuration, you can get totally independent and distinct project environments for each project (e.g. paths, design, modules, rights, etc.) with as many git repositories as you'd like per project.
Basically, you define one master config with the minimum (or default) configuration and then overload/override it with specific settings in the project's configuration file.

You can further integrate this flow into a CI environment like Gerrit and build systems, as well as using the native (!) Eclipse Mylyn RPC plugin to access all your tickets without even leaving your IDE (however, it's not just an ugly browser window inside Eclipse like in redmine...!)

Here's a post-receive hook for gitolite that works for multiple repositories. (Read the discussion here.

Works f... awesome, especially, if you're sick of having part of your stuff in the db and the rest in the filesystem!

The best way, is to comment in the code itself what the bugs are and what to rectify, but that doesn't work for all bugs (especially long term things that you may or may not get around to).

Next to that, keep the bugs listed in local text documents, but these can build up pretty quickly.

After that (and this is against what you were looking for, but will suggest regardless as it's very easy to setup) you can setup something like Trac, which is an extremely easy to setup and use bug tracking system, that you can also use to collaborate with other people (it also has an inbuilt Wiki, which is very handy for documentation and other dev notes).

The only additional point, is to make sure to include all of your bug tracking with your regular backup routine, along with your source (even better if you automate the backup to run once a day).

I am wary of cloud based services, where you may unexpectedly lose access due to downtimes etc. which can totally screw up your workflow; from my point of you, you really want full personal control of your bug tracking and source control systems.

I just switched from Trac to Redmine. The last straw was when I wanted to start making tickets depend on each other, or at least relate to each other. In Trac, this can't be done. Users have been requesting it for years and there is at least one plugin that mostly implements it but the general attitude I discovered when reading up on this was that a.) the main developers have no intention of implementing this officially and b.) plugins are a bad idea because they tend to break over time.

The extended discussion of this one issue and its lack of implementation (info here), as well as posts like this, give me the impression that while Trac may work well for a "simple" tracking system (as intended), it may be quite near end-of-life and future support and enhancements will be limited. Based on that, I can't recommend anyone start on it. Instead, why not just start with something that does more and is still under active development (i.e., Redmine)?

Trac (Python-based) or JTrac (Java/Wikit Based) work great. Of the two, Trac is definitely superior functionality-wise, but, I've found JTrac easy to deploy and plenty sufficient. See here:

Trac - http://trac.edgewall.org/

JTrac - http://www.jtrac.info/

So what was the benefit again?

So what was the benefit again?

What's the advantage of using the proprietary options over Trac? Especially since that can run on top of an advanced VCS like GIT, I think it's pretty close to ideal.

Trac is a Bugzilla, Wiki, and then some - plus it has thousands of plugins. Also easy to administer and manage. Great tool, I use it for many projects.

I've been using Trac for quite a while now, decent ticketing system for bugs & tasks combined with a wiki for everything else. Nice and simple.

From what you mention most of your requirements can be filled with the default install. Only subtasks might be tricky depending on what you want exactly, as I haven't needed to set up a hierarchy of tasks myself. Maybe one of the plugins would do the trick. YMMV.

It seems like that's not the point. The goal of having students write games isn't to turn them into game programmers, but to show them that programming can be fun, and then they can use their new skills to solve all sorts of problems.

I agree. For a couple of years, I have used The Battle for Wesnoth as a practical example of open-source development. Its markup language falls somewhere between HTML and real programming and thus has been working very well for students with non-technical background who typically run very far when programming is mentioned. The students form teams and create a mini-campaign, using version management, wikis and other typical tools (I've used Trac for that).

Also, it is similar in web development in the sense that it promotes/needs three separate skillsets - visual (the result should be aesthetically pleasing), technical (the result should work and follow standards) and verbal/creative (the result should tell something and do it in a correct manner). Thus, it can be used to teach various skills, stressing one or the other as needed.

I've had good results with some home-grown scripts that grab the project-specific details from a database and then generate the relevant config files using a templating system like Genshi. Run it periodically against the database, check in changes and email diffs to the admin.

I've always used cpp as my template engine, but then again, I've been doing this since the '80's.

I've had good results with some home-grown scripts that grab the project-specific details from a database and then generate the relevant config files using a templating system like Genshi. Run it periodically against the database, check in changes and email diffs to the admin.

I have good experience with Scrumworks for planning the development work using Scrum, Trac for PR/CR management and Subversion for source control.

you might want to consider trac ( http://trac.edgewall.org/ )

You're not alone in having trouble finding hardcore project managment solutions, particularly if you're looking for something to replace Sharepoint and MS Project. I use Trac for project management and software development, and I really like it. It requires a database, Apache, and Python. I know that 37 Signals uses it for their development work.

After using distributed version control for a very short time, I decided I will never go back to something centralized like Subversion. Only with a DVCS do I can:

- Get work done, with complete repository access, anywhere. On a train. In the rain. In a box. With a fox. Anywhere, any time, even when the network goes down or while I'm thirty thousand feet above an ocean.

- Create as many experimental branches/clones as I like, without making them visible to anyone else or cluttering up any shared namespace. (This is especially nice for capturing checkpoints when I have a lot of large, interdependent changes to make and the project won't work until they're all finished.)

- Get perfect, complete, automatic repository backups as a side-effect of working on a project. It's as hassle-free as I could ask for, and restoring is equally easy.

After quite a bit of reading, I ended up choosing Mercurial. After a year or so of using it regularly, and occasionally checking in on the other DVCS systems, I have always been glad of my choice.

Git was a contender, but is notoriously non-intuitive and awkward to use, and has never been a good fit on Windows. (I try to avoid Windows, but some of my colleagues still use it, and some of our projects are necessarily cross-platform.) Mercurial is similar to git in design, features, and speed, and is also very easy to use and works well on every major platform. Linus even called it out in his version control rant.

Bazaar was a contender, and I like their sponsor (Canonical), but didn't seem focused on performance enough for my liking.

More points for Mercurial:
- The folks on the email list are very knowledgeable, friendly, and helpful.
- It is very easy to extend.
- It has the blessing of some very large, high-profile projects. (e.g. Mozilla, OpenSolaris, Java's OpenJDK)

To the git users who use the gitk GUI for browsing revisions, Mercurial has a clone:
http://www.selenic.com/mercurial/wiki/index.cgi/HgkExtension

To the user who posted about the Tortoise GUI for Subversion, here's a link for Mercurial's equivalent:
http://tortoisehg.sourceforge.net/

To the user who posted about Trac integration, Mercurial will work too:
http://trac.edgewall.org/wiki/TracMercurial

Also of note, Version Control Blog occasionally links to some interesting articles:
http://www.versioncontrolblog.com/

1) wrong

2) wrong

3) Okay...now you're not even trying. Real ACLs are actually built into the main trac interface (i.e., roles, users, and linking permissions). They work right of the box.

Not that there are no (more or less dirty) workarounds

Look, these plugins just work. I don't know what the problem you have with them is. They're not workarounds - they're the main thing.

The only thing missing from Trac that I wish I could get easily is integration with active directory for permissions management.

trac + subversion works well.

Yes it does, very minor issue with Trac + svn tho, it needs to be on same server or you need to frig about with svn replications for the integration to work nicely.

The best issue tracker we've seen for Subversion, by far, is Trac. We're not crazy that it's written in Python (not that anything is wrong with Python - it's just proven difficult for us to hire people with language familiarity beyond PHP). However, the integration between Subversion and Trac appears to be very good.

trac + subversion works well.

1. Use trac as a repo browser.
2. Set up CVSspam for receiving commit notifications via email. Upon receiving those emails, then you can take action if the code affected happens to belong to your area of expertise (or if you have ideas to implement the code better or if you spot mistakes, etc.)

trac is a life-saver when you're tracking down code changes.

Just as one data point: here at SnapLogic, our product is open source. Myself and the other engineers are paid to work on GPLed software full time.

It's not just our core product. I'm responsible for the QA infrastructure, and in that role I've been able to contribute code to other projects we use: Django, Trac (one two three), Figleaf, and Buildbot (one two three four).

That's just what I have done personally, not to mention the other engineers. And it's not just something we do on the side - the company's upper management actively encourages us to contribute code back.

So in our particular case, just day to day operations intrisically seems to benefit the open source commmunity as a side effect. At least from my perspective (and by the way, I don't speak for SnapLogic). If something dramatic happened and we had to shut down, that would obviously stop.

[Holy cow, I'm being paid to write free software in my favorite language. Pinch me.]

Just as one data point: here at SnapLogic, our product is open source. Myself and the other engineers are paid to work on GPLed software full time.

It's not just our core product. I'm responsible for the QA infrastructure, and in that role I've been able to contribute code to other projects we use: Django, Trac (one two three), Figleaf, and Buildbot (one two three four).

That's just what I have done personally, not to mention the other engineers. And it's not just something we do on the side - the company's upper management actively encourages us to contribute code back.

So in our particular case, just day to day operations intrisically seems to benefit the open source commmunity as a side effect. At least from my perspective (and by the way, I don't speak for SnapLogic). If something dramatic happened and we had to shut down, that would obviously stop.

[Holy cow, I'm being paid to write free software in my favorite language. Pinch me.]

Just as one data point: here at SnapLogic, our product is open source. Myself and the other engineers are paid to work on GPLed software full time.

It's not just our core product. I'm responsible for the QA infrastructure, and in that role I've been able to contribute code to other projects we use: Django, Trac (one two three), Figleaf, and Buildbot (one two three four).

That's just what I have done personally, not to mention the other engineers. And it's not just something we do on the side - the company's upper management actively encourages us to contribute code back.

So in our particular case, just day to day operations intrisically seems to benefit the open source commmunity as a side effect. At least from my perspective (and by the way, I don't speak for SnapLogic). If something dramatic happened and we had to shut down, that would obviously stop.

[Holy cow, I'm being paid to write free software in my favorite language. Pinch me.]

Just as one data point: here at SnapLogic, our product is open source. Myself and the other engineers are paid to work on GPLed software full time.

It's not just our core product. I'm responsible for the QA infrastructure, and in that role I've been able to contribute code to other projects we use: Django, Trac (one two three), Figleaf, and Buildbot (one two three four).

That's just what I have done personally, not to mention the other engineers. And it's not just something we do on the side - the company's upper management actively encourages us to contribute code back.

So in our particular case, just day to day operations intrisically seems to benefit the open source commmunity as a side effect. At least from my perspective (and by the way, I don't speak for SnapLogic). If something dramatic happened and we had to shut down, that would obviously stop.

[Holy cow, I'm being paid to write free software in my favorite language. Pinch me.]

The most important thing about any documentation solution is that people use it, otherwise it is useless. To minimize the costs of using it, I suggest you find a solution that is similar to something people at your organization are used to using.

I had the same problem land on my desk a month ago. All of our policies and procedures were stored in a big notebook that was horribly out of date and that no one read. Since we use Trac for our dev department, people were used to the wiki formatting on it. I installed MoinMoin as a corporate wiki, which uses the same format.

MoinMoin is great because it uses basic authentication from apache, so you can authenticate it against whatever you have (like Active Directory), and people don't need another set of passowrds. It is simple to use and also easy to backup. Also, if you have a corporate intranet already, it is not difficult to integrate.

The wiki is great because anyone can modify it without alot of fanfare. However, if you choose a solution that is yet another thing to learn how to use, no one will take the time to use it. Again, the most important thing in my opinion is to lower the cost to the end user so that it is easier to post the information on the wiki than answer the same question again and again.

I've been using Trac for a couple of years now, also for external projects where customers directly submit tickets. It was a bit rough around the edges, but over the last year a number of good improvements have gone in without compromising the ease-of-use.

This is a ticketing system where people don't need an hour of training to understand what's going on. The integrated wiki allows for note-keeping (I tend to use it for tracking my hours too), and the SVN-browser is simple but useful.

If you need something more structured, try some of the CRM-packages. However I've been in your shoes, tried Trac and haven't looked back.

Trac runs on windows though why you'd want to is beyond me.
http://trac.edgewall.org/wiki/TracOnWindows

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies.

It provides an interface to Subversion, an integrated Wiki and convenient reporting facilities.

When researching a ticket tracking system to implement at my workplace I came with no experience in any non-proprietary system. I compared RT and trac side-by-side and found trac to be much more readable and user-friendly. Even for me, when setting it up, I spent an entire day trying to make heads or tails of the RT interface, while in a day I already had trac up and running and I was showing others how to log in and use it. Now that it is in production, what surprises me the most is the ease with which the non-IT department managers use it for tracking their tickets and project progress.

The irony of the situation is that I do specialize in Perl, which is why I went toward RT first. I assumed it would have been the better choice for making any changes to the underlying system, but in the process of working with trac I've learned Python enough to hack together a number of custom solutions for our needs.

Since I didn't go any further with RT after that first day, I can't say how well that would have worked, but in my case RT did leave a bad taste in my mouth.

JIRA isn't open source although it is quite nice and I use it internally at my workplace.

I might suggest Trac. It's an open source ticket management system integrated with Subversion. Probably doesn't have the extensive customer management features but with the wiki+ticketing is done quite well and can no doubt be used to satisfy the posters needs.

I implemented trac at my workplace as a change control and task management system. We use it for both internal projects as well as billable work, with a number of custom fields for supporting our quoting system and quality control. The built-in Wiki also doubles as our IT documentation repository, all in one easy to access location.

It is extremely extensible, and anything not readily available can be easily created. It didn't take much time to learn the class and data structures and I've modified existing plugins and written a few of my own to support our needs.

You can create DOMs that cannot be serialised to well-formed XML, like with document.createComment('--'). I don't really know anything about XSLT, but it doesn't appear to have had much success as a web templating language. Tools like Genshi seem to do much better at that, but anything outputting XHTML has to be very careful about avoiding all the little errors that might creep in and kill the document, so it's still safer to serialise to HTML at the output end of an XML toolchain - the browsers of your web site's users are rarely the best place to detect bugs in your server code, since those users are not in a position to do anything except leave your site.

<?python ... ?>

Trac might be worth checking out, although I don't think it will handle inventory and time spent. Maybe it does - I'm just an end user on one project (bug reporting and feature requests) - what do I know?

Nowadays, the sysadmins have installed Trac for us. Works very good, with integrated Wiki and all that jazz. I don't know how it stands up featurewise against Bugzilla, but Trac has a very flat learning curve. For instance, searching is one box. One search box. Compare that to the humongous Bugzilla search screen.

Start by reading Producing Open Source Software. Setup Trac or use Google Code Project Hosting. Make sure it's something you're really interested in doing and committed to spending a lot of time on it. Other people probably won't volunteer their time if they don't see at least one other person strongly committed to the project.

I ran through the same testing with my company and Trac came out on top every time. Yes I get a few errors (1 every few week and I am running MySql) but nothing that ever prevents me from using it.

Been using it for 9 months and love it. Set it up in a Virtual machine following the Ubuntu install sheet. Took a little over a couple of hours. Everyone loves it here and it is very customizable, even though you may need to learn a little python.

I'm in a similar situation (albeit we have about 30 employees) and I'm trying to convince everybody that we should use Trac. Its Python-based and can use SQLite, PostgreSQL or (experimental) MySQL. It also integrates nicely with a Version Control System (with Subversion preferred), has a built in Wiki system, reporting (with custom queries), timeline, roadmap of releases and search functions for when it starts getting a bit bigger.

At the moment we have an in-house solution which I'm responsible for maintaining, but it cant even touch anything thats available out there already

Only problem with Trac is thats its a touch difficult to install (if you know little about python and webservers). You have to install a webserver (though it does have a very limited one included), the python bindings for the server (as well as python bindings for other things such as the preferred database and VCS) and configure it all but once you get it up and running, its very customisable and there are loads of plugins available to help tailor to your needs.

Now if only management would give me the go-ahead...

My team just finished evaluating issue trackers, and the final three that we came up with were Bugzilla, Trac and Mantis for both technical and political reasons (Mantis is used elsewhere in the company but that's not saying much since we're so big).

We ended up deciding on Trac because of its wonderful integration with SVN, we are using a lot of python in other areas of our team and it is pretty well documented, there is a great wealth of easy to install (but not always well written) plugins and other than some quirks with the ClearSiler package it is no harder to install than any of the other packages we evaluated. If you use the subversion repository (which can be used for more than code), it is really easy to make links to other tickets, specific documents inside the repository and specific revisions.

However, Trac requires Python (you'll probably want 2.5 as the next release will require it) and either mod_python or fastCGI with a compatible webserver in addition to a subversion repository. Depending on what database you choose (SQLite3 is the default but you can also use Postgre and MySQL but the MySQL support isn't perfect yet) you will have to install the appropriate Python bindings for it and if you install the current stable release you will also need ClearSilver (but make sure you check the Trac Wiki before you install as people seem to have trouble unless they use specific versions of ClearSilver).

My team just finished evaluating issue trackers, and the final three that we came up with were Bugzilla, Trac and Mantis for both technical and political reasons (Mantis is used elsewhere in the company but that's not saying much since we're so big).

We ended up deciding on Trac because of its wonderful integration with SVN, we are using a lot of python in other areas of our team and it is pretty well documented, there is a great wealth of easy to install (but not always well written) plugins and other than some quirks with the ClearSiler package it is no harder to install than any of the other packages we evaluated. If you use the subversion repository (which can be used for more than code), it is really easy to make links to other tickets, specific documents inside the repository and specific revisions.

However, Trac requires Python (you'll probably want 2.5 as the next release will require it) and either mod_python or fastCGI with a compatible webserver in addition to a subversion repository. Depending on what database you choose (SQLite3 is the default but you can also use Postgre and MySQL but the MySQL support isn't perfect yet) you will have to install the appropriate Python bindings for it and if you install the current stable release you will also need ClearSilver (but make sure you check the Trac Wiki before you install as people seem to have trouble unless they use specific versions of ClearSilver).

Depending on what you want, I'd suggest either Trac ( http://trac.edgewall.org/ ), or OTRS ( http://www.otrs.org/ ). Trac has a pretty basic ticket system, but that's combined with a Wiki and Subversion (don't know if you do coding), while OTRS is a quite powerful ticket system (admittedly, it looks like crap, but it does get the job done) with email piping and all the other things you would expect.

We've gone through a similar experience when we grew from a team of 2 to a team of 8 in 3 months. Things we learned to be helpful in the way of tools:

- A Subversion repository for every project, and one repository per person, to host "private" projects. Also, TortoiseSVN for a windows shell integration with Subversion.

- Install Trac for every subversion project. Use it for writing documentation, and for following up on issues by posting Tickets. Tickets help a lot in maintaining the focus on problems and future developments. The integration with Subversion changesets and milestones is bliss.

- Install the appropriate modules for Trac for permission management, and allow your customers and testers to post tickets themselves. Eases up a LOT in the way of issue tracking and fixing bugs fast. It's a great way to have other people build your to-do list dynamically.

- Use frameworks for development. If you're programming with PHP use Symfony for real programming (and not just random code bits).

- Have a shared folder for files.

- Use an appropriate database backend and install common tools for database access (phpMyAdmin, pgpPgAdmin).

- Use the right tools for the job. As an example, remmember that MySQL works well as a fast database backend. But if you stick to MySQL for real applications where integrity and object mapping is relevant, you won't be doing real DB development unless you use views, functions and stored procedures. If you don't have these features, you'll never use them. If you use them, use PostgresSQL.

- Buy a billboard, a big one, and have a handy set of markers available. Do not underestimate the power of a billboard.

These are just things that worked and still work for us. There are plenty more things you can do, but first step is realizing the NEED for change, and getting everyone to work towards that.

Perl, Python and Ruby zealots need not respond!

Good thing, I'm only pro-Python, not a zealot then. I switched a while back, and got a big productivity boost. mod_python+PostgreSQL+Kid for templating works nicely. Just moving over to Apache 2.2 now, and considering replacing Kid with Genshi. Currently hosting legacy PHP apps on a separate proxied Apache instance, but looking at running them as Python WSGI layers with WPHP.

There's a lot of movement in the Python web development space right now - Turbogears, Django, web.py, Pylons, WSGI... it's unlikely that there's nothing that would appeal to you.