Hi Mark, I assume keeping track of changes is exactly what SCM is all about. As such, while subversion is already keeping logs of those actions, there should be no need to store a second reference in a trac ticket. What for?
We're also commiting changes that are not required by a ticket, mostly technical changes in the project setup but also general code enhancements. It's perfectly acceptable to record those changes in the subversion change log only. Every release to the customer gets tagged and by comparing the revision numbers of the current and last release we compile a complete changelog for the current release. No need for extra tickets. One issue remains: If a code change would need some files and attachments as well as further information about who planned it, who requested it... then it might be appropriate to open a single ticket for this issue (but close it again when it's done). Just my $.02. Kind regards, - Christian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mark > Sent: Friday, March 17, 2006 8:35 AM > To: [email protected] > Subject: [Trac] Using tickets as logfiles > > > 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. > > 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. > > In my mind, I disagree about how the ticket is being used because they > are supposed to initiate action rather than just record it. > 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? > > Mark ________________________________________________________________________ This email has been scanned for all viruses by the MessageLabs SkyScan service. ________________________________________________________________________ _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
