Hello,
we really appreciate the use of trac in our development group. My goal
in using trac is to ''trac'' the changes (bugfixes and enhancements) for
each version and each maintenance line of our software. Sincerely trac
has a few shortcomings in this area that plague me in keeping the
overview. I still think, that the new workflow enhancements will not
solve these issues really.
I think, that our product life cycle is similar in most environment. We
have the top of the line product and at least two actively maintained
older product lines, where we need to provide support and bugfixes. The
versioning of the software is also very simple in the common dot
separated form: major.minor.patch level.revision.
If a bug is encountered in a specific production line in most cases the
fix is also ported to at least one of the other production lines. So in
our case, and I expect this is the same for all other environments also,
the issue and the "fixed in" version is a 1:N relation ship. I would
also say, that an issue is actually tied to a specific file/path and a
specific revision of the archive, and is therefor also persistent in all
branched and derived files/folders until somebody comes by and fixes it
for this specific version. Additionally it is possible that the issue is
reopened or encountered in a "subversion relational" independent
version, e.g someone copy&pasted the same problem from one file into
another.
My main problem with the issue system is, that it can not capture this
one to many relation. So if you close a ticket, it is closed for all
versions. Esp. the "duplicate" and the "reopen" possibility are very
problematic in this case.
a. if you close an issue and set the resolution the "duplicate" the
issue is formerly closed. A quick glance over the closed tickets will
lead to the assumption, that this issue is also solved. But this is not
the case. It is only duplicate. The closed state depends on the fact of
"master" issue.
b. reopening will lead to the fact, that you loose the historical
information about the fact, that this ticket was closed already
somewhere in the production line. Esp. if the bug was closed in a
specific production line and reopened in the main line.
Every possible solution and operating procedure I came up in order to
minimize the impact are very fragile, if unknown developers do not
correctly update the milestone and version fields when performing
specific actions.
So in the current state, it is only possible to get a quick overview of
the complete state, but you can not solve the following tasks
1. list all open and known issues against a specific version or product
line
2. automatic generation of release notes if tickets, due to reopened
issues.
I do not have a solution to the above problem. One thing that comes to
my mind is the separation of the "issue information" and the
"organizational information", so that one can refer to the same ticket
multiple times. Additionally it would be great to have a tighter
integration with subversion, since this would automatically generate the
information about the "dependant" branches for the issues. This could be
simple "revision" field in the issue information, or a custom property
in subversion. Finally it would be great to have some kind of knowledge
about the version structure. So that trac automatically knows that
1.10.2 is a bugfix release of 1.10.1 and that 2.0 is a successor of 1.0
and all bugfix releases, even if 1.10.2 is created later in time than 2.0
Does anybody else have the same problem, or is it only me? Do I expect
to much from trac?
Best regards
Dirk
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
