Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Pardon the all-too-typical off topic: woa, Trac! I haven't seen that in a long time. I have fond recollections of its customizability. Is it still being used in anger and improving, or is this just a legacy system we're looking at?


I’ve been using a Trac+Svn combination for my personal projects for 13 years now. I mainly use it for repository browsing, as I don’t do bug/task management for any of my personal projects, but it’s cool seeing repositories 11 or 12 years old. If it ain’t broke why would I fix it?


Trac was/is truly to most awful bug tracking system. I mean a primary function of a bug tracking system should surely be to accept bug reports from users, yet Trac manages to make that the least discoverable and least usable feature. Even things like subscribing to an existing bug report or listing bugs are very hard to find. I would say "impossible" for ordinary people, but will get accused of exaggerating, but go and look at a Trac-based bug tracking system some time to see what I mean. One at random: https://trac.osgeo.org/geos


WebKit uses Bugzilla: https://bugs.webkit.org


Bugzilla is also pretty awful (and I say this as someone who uses Red Hat's Bugzilla instance hourly in my job).


Accepting bug reports from users isn't necessarily a goal of bug trackers: in some workflows mailing lists are better for unconfirmed bugs, the actual bug tracker is for confirmed bugs (read: not submitted by users). It works better that way a large amount of the time.


You certainly want a good way to sort, classify, combine and remove reported bugs (which Trac also makes awful), but you should never put up barriers to accepting bug reports. My rule of thumb is that every bug that someone reports affects 9 other users who couldn't/didn't report it. (Probably with Trac it's 1:99 because of how difficult it is to use.)


If you tell people to submit bugs to a mailing list, that means that devs will manually confirm bugs before putting them onto the bug tracker: this gives an incentive to get them taken care of faster, because right as it's added, someone who knows the codebase has a general idea of what's wrong.

Mail is standard, so it's not really a barrier. It kind of lessens the Caps-Lock Warriors of Bugzilla-like systems, though.


Then they have to subscribe to the mailing list, which is another set of extra steps. Some people only know the web exists and don't even know mailing lists are a thing.


url: projectpage.tld/bugs

Hi! If you're here, you must have found a bug. Send an email to XXX@projectpage.tld describing the bug, and we'll see to fixing it as fast as we can, and we'll alert you when we've started working on it!

You don't have to have them subscribe, necessarily.


As soon as someone thinks about reporting a bug, they’re already doing you a massive favour. Making them go away and write an email (which many people don’t often do any more) you’re already going to be testing their patience. You should be bending over backward to accept the report.



Which is basically what I said in https://news.ycombinator.com/item?id=21490182 Never put up barriers to accepting bug reports. Now does Trac help in any of this? No.


Trac is better than the GitHub/Bugzilla model, in any case, in my opinion.


Django still uses Trac. https://code.djangoproject.com/query

It really is awful.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: