Hacker News Reader

Comment by pjtr | Hacker News Reader

It seems not that many people have enough time and long-term interest in contributing significant improvements to such projects.

GenericTrac was mainly a plan by Christian Boos, who worked a lot on Trac in ~2005 - 2013, but has not actively worked on it much after that.

Apache Bloodhound was mainly triggered by one company (WANdisco), which has lost interest in it. Of the few remaining people, Ryan J Ollos has since become a Trac core developer instead, and has been keeping very active there.

Recently Gary Martin (formerly(?) WANdisco) "restarted" Apache Bloodhound as a Django app, not based on Trac anymore.[2]

> Trac has many serious shortcomings

I don't disagree, but would be interested in what you think they are.

[2] https://lists.apache.org/list.html?dev@bloodhound.apache.org...

View on HN

First let me say that I haven't looked at Trac since I ditched it from production (prior to the Bloodhound incubator). So don't expect this to be fair criticism today.

> It seems not that many people have enough time and long-term interest in contributing significant improvements to such projects.

I am not convinced that is the only reason. The trac mailing list was (in my opinion) hostile to people that showed up with an idea and willingness to work on it; nobody would give encouragement or guidance and there was usually a "fk off and fork" or two in there. People aren't going to stick around to contribute if the maintainers/community are not interested to include them. That is/was a serious shortcoming.

The data model was not well thought out, with lots of UNION and UNION ALL in the queries, row-modelling things that should be normalized, and so on. That's probably my #1 technical issue, in terms of the code, it was hard to correctly add functionality because things were just read into RAM and manipulated there (expert SQL knowledge is of no use when working with the trac database)

The switch of templating engine did not make the codebase simpler, but instead made everything more convoluted and difficult to work with.

The primary issue though, was the lack of Milestone customization, and the incredibly poor performance. I had to implement custom search, custom indexes, custom reports, and custom everything else. And this was a 5-person team, using only ticketing (no repo, no wiki, nothing).

I would say the mailing list has become much less hostile and more supportive then.

The data model has not changed much, so that criticism is still relevant.

The templating engine has been switched again (ClearSilver -> Genshi -> Jinja). I don't know if you refer to the first or the second switch. I also don't know if this was an improvement or just even more churn.

Lack of Milestone customization: I'm not sure I understand.

Poor performance: How many tickets do you have?

> the mailing list has become much less hostile and more supportive then.

Glad to hear that! Running an open project is hard.

> [...] switched again (ClearSilver -> Genshi -> Jinja)

Genshi was current when I used it; I wasn't aware it had switched to jinja (or it slipped my mind by now..)

> Lack of Milestone customization: I'm not sure I understand.

Back then, there were no custom fields for milestones, and the code didn't make it easy to do. Of course, this means you need changes to search facilities, and any other parts of the codebase. I had to write that also, and the target workflow was not at all complex.

As for the performance, we had about 20k tickets and 2k milestones when the system was replaced. By then it had been completely unusable for a long time.

Honestly, the only positives I have to say about Trac concern real-world usage by a hacker. Once you've learned it, and hacked it to your liking, it's very productive. But to get to that point, it's a sixty feet tall stack of ugly hacks, and frankly I would not recommend it to anyone...

Again to be clear, I did not look at the trac repo in many years, nor do I intend to.

Ah, I thought my ~300 milestones was pushing it. :)

I see. Milestones still have no custom fields. Did you ever send your customizations upstream?

No, unfortunately it was nowhere near good enough for that, it was just massacred to solve the problem.. Plus it was built on probably 20 patches from trac-hacks in the first place.

Very hard to find the time to upstream something like that when you are on a limited budget in the first place..

So "It seems not that many people have enough time and long-term interest in contributing significant improvements to such projects" wasn't that wrong. ;)

Reply on news.ycombinator.com