Trac gardening & feedback

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

Trac lint sounds like a great idea.

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

- Rob

Rob Sanheim wrote:

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

Trac lint sounds like a great idea.

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

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

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.

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

Jeremy Kemper wrote:

Rob Sanheim wrote:

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

Trac lint sounds like a great idea.

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

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.

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.

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

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

Aha :slight_smile:

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

Jeremy Kemper wrote: