Mark wrote:
I'm a little bit concerned about a certain ticket issued by one of our
programmers. He's using this ticket as a placeholder for minor issues
that don't have tickets. For example:
1. He fixed a minor spelling error in a field
2. He changed the background color of a form
3. He changed the name of a column in a database
Since he thinks that all these are too minor to be issued their own
tickets, he simply commits each of the above changes one by one while
referencing this "generic" ticket. In other words, the generic
ticket's lifespan is infinite and may never close.
IIUC, the intent here is to be able to ''categorize'' changesets,
or is it just because you require to have a reference to a ticket
in each changeset?
If it's the latter, maybe you should simply relax your rules :)
If it's for the former reason, that would be an use case for the
TracCrossReferences features. With that, one could either:
* write in the changeset message that "this is a MinorEdit".
Then, using the backlinks for the MinorEdit wiki page, one
could retrieve all the changesets referencing this page.
* write an explicit 'tag' relation in the log message:
<<tag MinorEdit>>.
Then, one could write some query to retrieve all the changesets
tagged that way, like [[Sources(<<tag MinorEdit>>)]].
There is also another ticket for deprecated or deleted files. That is,
if the programmer deletes a file no longer in use in the project he
will then commit his latest copy and in the commit message type in
something like "re #40". Where #40 is the ticket number for another
generic ticket whose purpose is to log all the commits where files
where removed from the project.
As someone else wrote, this information is already in the repository,
even in the cache. It should be easy to write a macro, e.g. [[Attic]]
that would produce a list of all the files that have been removed.
In my mind, I disagree about how the ticket is being used because they
are supposed to initiate action rather than just record it.
Well, see that as an inventive use of the system :)
Furthermore, tickets should have a finite lifespan. On the other hand,
I also understand that keeping a logfile of deleted files or minor
issue resolutions might be of some use to the programmer. My questions
then are:
1. Is this an acceptable way of using the ticketing system?
2. If not, what other convenient way is available that will allow the
programmer to log minor changes and file deletions without using a
ticket?
As I said, the above suggestions would only work using the trac-xref code,
and if can suggest that you could try it out, be aware that it's now a bit
outdated w.r.t to the current trunk.
-- Christian
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
