Trac gardening & feedback

[Jeremy Kemper]

Hey all - Zed Shaw has crafted something like a lint for Trac.  It checks for malformed tickets (empty reporter, no version, etc) and closes them as 'wontfix' with an explanation.  Is this sort of behavior appropriate, or too brusque? The idea is to fix, update, and reopen, not to punitively close.

Trac has been updated on the new box (to 0.10dev) and includes a spam filter, so we have a tool to combat that annoyance. Also, the RSS feed now includes comments on tickets so older tickets under development won't disappear from the radar.  Anything else we can do to lube the process?

Best,
jeremy

[Rob Sanheim]

Trac lint sounds like a great idea.

Does this mean that adding new tickets now works, and all those issues
are sorted out?

- Rob
--
http://www.robsanheim.com
http://www.seekingalpha.com
http://www.ajaxian.com

[Justin Forder]

It would be nice to know what the problem with Trac was, and how it was
fixed.

I'm working on a large project with all user stories, developer stories,
engineering tasks and defects in Trac - it would be a disaster if it
stopped working for us.

regards

Justin

[Bryan Liles]

Its a good idea, but it might not work for dev.rubyonrails.org as you
described. Every ticket doesn't need a version. I still think
'wontfix'ing tickets with out a reporter is a good idea.

[Jeremy Kemper]

Hey Justin - Trac has worked great on the whole, but needs care and feeding. Unless a ticket is quickly resolved it will drift off the timeline (the RSS feed is how most keep tabs on Trac) and out of memory.

So it works well for tickets that are poor or wonderful, but not so well for your average ticket which needs work (usually tests or docs).  You had to add yourself to the CC field on every ticket you wanted to participate in. Just doesn't work. This is why I've been resolving tickets as 'wontfix' and 'invalid': the resolution shows up in the timeline so  the ticket gets its share of fresh eyeballs.

By having all ticket activity show up on the timeline, including comments and new attachments, our bread & butter tickets can compete for attention they deserve.

jeremy

[Justin Forder]

Hi Jeremy - that all sounds eminently sensible.

I was really asking about what happened to make the Rails Trac
completely unusable for days on end. Was it lack of capacity,
misconfiguration, a bug, or what? It's scary to see a key piece of
infrastructure fail and take some time to fix.

thanks

Justin

[Chris Mear]

On 20 Aug 2006, at 4:59 pm, Bryan Liles wrote:

> Every ticket doesn't need a version.

Doesn't it? I agree that not every ticket is a 'here is a bug I found
in a particular version' ticket, but even new-feature or patch
tickets should say what version they were developed against.

With that in mind, if we are going to make the version field
compulsory, we ought to have an 'Edge' version in there along with
all of the released version numbers.

Chris

[Jeremy Kemper]

Aha :)

We were using Trac backed by SQLite and had reached its capacity - receiving db lock errors and whatnot.  So we started the move to PostgreSQL, which failed horribly because the database was located on the same disk as the mail queue and the python drive leaked connections under FastCGI.  This was just poor planning, not really a Trac deficiency.  Jason set us up on mod_python and eliminated the disk contention.  Ahh.

jeremy

[Joe Ruby]

The requests pages seems to need an SQL query:
http://dev.rubyonrails.org/report/2

Joe

--
Posted via http://www.ruby-forum.com/.

[Justin Forder]

Thanks, Jeremy.

Bad that the driver leaked connections under FastCGI - I suppose the
planning could have been better, but de-risking these things isn't easy.

It's those unknown unknowns....

regards

Justin