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?
On 8/19/06, Jeremy Kemper <ra...@bitsweat.net> wrote:
> 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 Sanheim wrote: > On 8/19/06, Jeremy Kemper <ra...@bitsweat.net> 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.
On Aug 19, 2006, at 10:25 PM, Jeremy Kemper wrote:
> 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?
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.
> Rob Sanheim wrote: > > On 8/19/06, Jeremy Kemper <ra...@bitsweat.net> 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.
Jeremy Kemper wrote: > On 8/20/06, Justin Forder <jus...@justinforder.me.uk> wrote:
>> Rob Sanheim wrote: >>> On 8/19/06, Jeremy Kemper <ra...@bitsweat.net> 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.
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.
On 8/20/06, Justin Forder <jus...@justinforder.me.uk> 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 Kemper wrote: > On 8/20/06, Justin Forder <jus...@justinforder.me.uk> 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.
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.
