Alright folks, as Jeremy K. mentioned I’m working on a set of
“triage” scripts for the Rails trac using RFuzz to go through all the
tickets and clean them out. I’ve talked this over with the core guys,
and they’re behind it.
I’m calling this set of scripts “THE MAGGOT” thanks to hasmanyjosh.
Basically THE MAGGOT (all caps) will be run against the trac tickets
periodically and will auto-reject any tickets that don’t meet certain
criteria.
The goal of this is to keep the rails patches and trac tickets focused
and actionable. Your tickets won’t actually go away, they’ll just be
flagged “wontfix” with a terse little message about what’s wrong with
it.
Everyone should take a look at the list and feel free to comment on the
results. REMEMBER NOTHING HAS BEEN DONE YET. We’re just exploring it.
Ok, first, here’s the writeup about the criteria and the list of tickets
on the chopping block:
What??? Why do that when you could just move trac to google groups,
email everyone that has submitted a ticket the entire trac database to
look at and make sure they don’t have a bad ticket, then post it on
some obscure webpage somewhere and go have a pizza?
Sorry, couldn’t resist:) That cleanup looks pretty reasonable. What
about tickets that were submitted without a patch for older versions
that address a problem that still exists?
Sorry, couldn’t resist:) That cleanup looks pretty reasonable. What
about tickets that were submitted without a patch for older versions
that address a problem that still exists?
These are just the tickets we hope to expose: old, unattended issues
which
are little better than closed already.
It makes no sense for people to test against 1.1.6, and provide a patch
to 1.1.6, but then have to declare it to be for 1.1.1.
Just following up on this - is there some reason 1.1.1 is the latest
version in trac? Shouldn’t there also be an “edge” version, for
defects that only exist in trunk?
Please, please can someone add the missing versions in Trac?
It makes no sense for people to test against 1.1.6, and provide a patch
to 1.1.6, but then have to declare it to be for 1.1.1.
Just following up on this - is there some reason 1.1.1 is the latest
version in trac? Shouldn’t there also be an “edge” version, for
defects that only exist in trunk?
Yes - there should be 1.1.2 - 1.1.6 and 1.2.edge. They’re sitting in a
basecamp todo begging to be checked off
Please, please can someone add the missing versions in Trac?
It makes no sense for people to test against 1.1.6, and provide a patch
to 1.1.6, but then have to declare it to be for 1.1.1.
Just following up on this - is there some reason 1.1.1 is the latest
version in trac? Shouldn’t there also be an “edge” version, for
defects that only exist in trunk?
Yes - there should be 1.1.2 - 1.1.6 and 1.2.edge. They’re sitting in a
basecamp todo begging to be checked off
It does seem odd that someone should put a lot of effort into upgrading
Trac itself, while the metadata Trac contains is left four months out of
date!
It should be part of the Rails release process to define the new version
in Trac.
Justin
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
