Hey all - Zed S. 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
On 8/19/06, Jeremy K. [email protected] wrote:
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?
On Aug 19, 2006, at 10:25 PM, Jeremy K. wrote:
do to lube the process?
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.
On 8/20/06, Justin F. [email protected] wrote:
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.
jeremy
Rob S. wrote:
On 8/19/06, Jeremy K. [email protected] wrote:
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
Jeremy K. wrote:
Best,
stopped working for us.
‘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
On 20 Aug 2006, at 4:59 pm, Bryan L. 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
On 8/20/06, Justin F. [email protected] wrote:
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.
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
The requests pages seems to need an SQL query:
http://dev.rubyonrails.org/report/2
Joe
Jeremy K. wrote:
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.
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