Hi, sorry for not answering earlier, esp. there was some interesting feedback for this issue.
>> I think, that the issues and issue status are not necessarily a 1 to 1 >> relationship. For example you can have an issue in the software that >> will affect one release branch and the current trunk. You need to close >> the issue in both pathes, in order to be sure that you have solved the >> problem forever. Currently I copy tickets and cross reference them, but >> this is extra overhead. >> > > I think there are many ways we could address this in the future. > The first idea would be to have a 1-n relationship from tickets to > milestone, and declare a ticket closed when it's fixed in all the > relevant milestones. > Is there an explicit need to finally close a ticket? I don't think so. If the ticket doesn't show up in any relevant branches, you can consider the ticket closed. But a lot of tickets in trac itself, which are closed in later versions are still open in earlier versions. No one is interested in this any more. I would prefer to distinguish between static or ticket related information, like component or keywords, and version or source related information like milestone and priority. Even the "assign to" field could be different for two different maintenance paths of the software. The static or ticket related information is maintained as before, and is a continuing list of changes to the ticket throughout all versions. The version or source related information is managed for every version, where the ticket plays a role. In an ideal world, this relationship is deduced from the source archive itself, e.g by assigning the ticket to a specific revision number by setting a custom subversion property or whatever. In an non ideal world the human has to enter this information, e.g by telling trac how versions are related. Therefor it is important, that trac understands how versions work. It does not matter whether they are numbered or hierarchical. I can be any ordering system, but trac needs to deduce from the version number, that if a ticket is assigned to version 1.12, that it is persistent in version 1.12.1, 1.12.2, ... and also in 1.13, 1.14. Closing the "ticket for version" 1.14 will not close it for 1.12.2 and so on. Consider the following scenario: * someone will find a bug in version 1.10 and will file this bug and assign the version 1.10 to the bug * a developer will find, that this bug was introduced in revision 1234 and will assign the bug to this revision. * revision 1234 was also the base for version 1.9, so the bug is also persistent in release 1.9 * A query for the 1.9 release will show, that there is a new bug. ==> Up to this point, there is only on ticket and one ticket properties block * Some QA person will assign a high priority to esp. this bug in version 1.9 and will request to have it fixed in the next maintenance version 1.9.5 * He will add a new target milestone 1.9.5 ==> Here we have a second block of ticket properties. * The milestone will be assigned to one developer, not necessarily the developer how will fix it for the trunk * The developer will fix the bug only within the 1.9 maintenance line and will close the ticket for 1.9.5 ==> Here only the second properties block is closed. Using subversion as the version archive backend this could be solved by a tighter integration with subversions custom properties, e.g like the svnmerge properties. You would assign a ticket to a specific revision, and as long as you don't close it in another revision the ticket will show up in the leaf of this branch. > Another idea would be to use sub-tickets, with sub-tickets for detailing > the status of a particular issue and the particular way it should be > solved in each branch. The cross-referencing would come for free > (providing the SubTickets feature is implemented, of course). > I don't think it is necessary to create a different history for every different version branch. But it could be a handy feature. On the other hand this could also be used as a kind of "customer" / developer separation. The customer will enter a ticket, the developers will continue to work on a subticket without giving all details to the cutomer. And finally when the subticket is closed, the customers ticket will be updated also. Thanks for listening Dirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
