Trac Development to support Change and Requirements Management
John M Camara
requirements management. They initial were looking only at commercial
products but I have been pushing for an open source solution. I felt
that Subversion & Trac already handles at least 60% of the
requirements and customizing Trac and building a simple Requirements
Management system would cost close to what it would cost to buy the
commercial products.
Areas in Trac that I see need to be worked on are:
* creating a plugin to manage custom permissions with web interface
* permissions web page
* make it easier to use when large numbers of users exist
* separate forms for adding users and roles (just cosmetic nothing
would change in the back end)
* add a view for displaying roles vs users
* ticket
* multiple ticket types (subclasses of Ticket)
* support for ticket hierarchies (child tickets) by adding a
parentTicketID field
* ticket fields
* defining and modifying custom ticket fields through a gui
* custom fields get assigned to a ticket type
* define the work flow transitions in which fields are writable,
required, readonly
* work flow
* separate workflows for each type of ticket
* add a gui for defining and modifying ticket workflows
* SQLAlchemy migration
* and some additional template customizations
Most of these changes are minor changes to Trac or simple plugins that
need to be created except for the SQLAlchemy migration.
The largest piece of work required in my proposal would be to create a
requirements management system. This system would have to support
features like
* Managing requirements for multiple requirement documents
* Traceability between requirements from within a requirements
document, to a requirement in another document, external references,
or to files in the repository
* Integration with Trac's ticket/workflow
* Management of different views of the requirements
* Version control of requirements
* managing requirement properties
* support for multiple requirement document types - i.e test case,
user requirements, etc
* support for multiple requirement types - i.e use case, functional
requirement, marketing, unit test, etc
* etc
I have noticed lately that more and more large companies are starting
to adopt Trac so maybe some of you that are reading this would also be
interested in this development. If you have any interest in this
project let me know. Especially if your interested in doing some of
this development or if you company may be interest in sharing the cost
of some of the development.
Any support from the community will greatly improve the chances that
my company will accept my proposal. If they do accept it they would
be willing to spend a reasonable amount of funding for this project
although I don't know the exact level at this time. This would be a
great opportunity for Trac to gain additional corporate users as well
adding some new features to Trac, especially completing the SQLAlchemy
migration.
If my company accepts the project (decision to be made mid July)
development would be ramped up quickly as a beta would be expected by
the end of the year.
John
Christopher Taylor
MOST of what you are talking about is currently possible via some of
the plugins at Trac Hacks. Just google it, it'll show up as the first
hit. If you need some assistance figuring out how to combine these
plugins to get the desired capabilities, let me know. I can walk you
through it.
-Chris
David Abrahams
on Wed Jun 27 2007, John M Camara <john.m.camara-AT-comcast.net> wrote:
> I have noticed lately that more and more large companies are starting
> to adopt Trac so maybe some of you that are reading this would also be
> interested in this development. If you have any interest in this
> project let me know.
I only ask that you post the results of what Chris T. tells you and
anything else you learn to the Trac wiki.
I'm currently working on
http://trac.edgewall.org/wiki/TracMultipleProjects/ComprehensiveSolution
so I have my hands full with another project that companies will care
about, or I'd help.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com
Christopher Taylor
we have a very robust setup ... let me crank out some notes and I'll
see what I can come up with....
-Chris
tr...@nogga.de
are we working for the same company ;-)
I would like to add a few more wishes to your list:
* Ticket System
* attach tickets to revisions and branches in subversion to be able
to query which issues are still open in which branch
* different solutions for issues in different branches
* separation of "milestone" and "target version"
* a concept of a version and the relation between versions
Dirk
John M Camara schrieb:
Christopher Taylor
and some sql wizadry ....
for that one, try a custom field with a trac/code-browser url and then
write a query to search based on an input path. (what you would
search for is everything that has a prefix of <input>).
don't understand #2
#3, don't understand why ... if a milestone is a future version ...
where is the problem
#4, the concept of a version is in there .... what kind of
relationships b/n versions are you intending?
-Chris
John M Camara
On Jun 28, 10:32 am, "Christopher Taylor" <chtay...@gmail.com> wrote:
> John,
>
> MOST of what you are talking about is currently possible via some of
> the plugins at Trac Hacks. Just google it, it'll show up as the first
> hit. If you need some assistance figuring out how to combine these
> plugins to get the desired capabilities, let me know. I can walk you
> through it.
>
> -Chris
Thanks Chris,
I'm aware of the plugins at Trac Hacks and some of them will be used,
others may need some additional capabilities, some of them need to be
refactored to take advantage of the ticket-workflow and others are
implemented in ways that I feel are not as useful as they could be
such as the MasterTicketPlugin.
The MasterTicketPlugin which has a field that specifies all it's child
tickets but I would prefer to save the parent ticket ID in the child
object and would prefer a better approach to managing the child
tickets besides a comma separated list of IDs. A little bit of AJAX
functionality in the parent tickets to manage the child tickets would
be very useful and would take this plugin to the next level. I'll add
that the plugin does work just fine for simple use cases for which I'm
sure it was designed for.
There are no plugins to my knowledge to provide a UI for customizing
workflow which is understandable since it's a new feature.
I also don't believe there are any plugins to control which fields are
displayed, writeable or required based on the action the user will
perform on a ticket. The implementation of this is fairly easy (at
least hacking it in) and I have demo code already developed. Just
need to create a plugin and create the UI for it's administration.
Having ticket subclasses would be very useful but will be much easier
to implement with SQLAlchemy. This would allow for a different set of
custom fields and a custom workflow for each type of ticket. That way
you could handle bugs with a different process than say a new feature
request, or a QA task, or etc.
This last feature would also be useful for creating and managing sub
tickets.
John
John M Camara
On Jun 28, 11:30 am, "Christopher Taylor" <chtay...@gmail.com> wrote:
> Hmm, maybe I should spend some time and post it to the wiki myself .....
>
> we have a very robust setup ... let me crank out some notes and I'll
> see what I can come up with....
>
> -Chris
>
Thanks. I'm sure many will find your notes useful.
tr...@nogga.de
> this too is possible....... requires a creative use of custom fields
> and some sql wizadry ....
>
which field with which information.
> for that one, try a custom field with a trac/code-browser url and then
> write a query to search based on an input path. (what you would
> search for is everything that has a prefix of <input>).
>
I'm currently looking for a hook script, that will fill out this
information whith the checkin.
> don't understand #2
>
Our software goes through a lot of version and fixes. We have the normal
major.minor.revision.buildnumber style for the version number. In most
cases I can explizitly state in which version/revision a bug was
introduced, or a feature was missing. Since we service at least two
releases of our software, I have to fix the same bug at least three
times, one time in the trunk, and two times in to different releases. If
I could separate the solution for each release of our software, I could
close the ticket one time for the trunk and two times for the branches.
Additionally if you could attach a ticket to a revision, e.g. via a
custom property in subversion, you could easily tell for each branch,
which tickets are open an which are closed in specific branches.
Currently I have to copy the ticket for each branch, and I have three
ticket stating the same information.
For me the issue and the resolution is a 1..n relationship.
> #3, don't understand why ... if a milestone is a future version ...
> where is the problem
>
if you track hardware and software issues within trac and also customer
dates, the concept of milestone and "future version" does not mix very
well. E.g. you must have finished a specific task for a specific
milestone, but this does not necessarily mean, that this will result in
a specific version. A bugfix or feature is sheduled for a specific
future version. A milestone is simply an event, where a few things have
do be done. Naturally you can use the same concept, but in respect with
#2, I often want to distinguish between milestone and future version.
> #4, the concept of a version is in there .... what kind of
> relationships b/n versions are you intending?
>
1. version ordering is not identical to natural ordering, e.g. 1.1,
...1.9, 1.10, ... and so on.
2. The most common use case is: which bugs are fixed in version 1.17.5
and please list all issues, also the one from 1.17.4, 1.17.3, 1.17.2,
... 1.16. In this moment you need to now, which version is the ancestor
of which version in order to build. Again, everything can be done with
different queries, but if trac would understand this, it would be
easier. Additionally, not everybody uses this concept of versioning.
E.g. one could use names to identify his version. But still one version
will follow another, and version version is a bugfix release of another.
and this is an important relationship
3. If versions are directly understood by trac, and the ticket is
assigned to a specific release/version I would be able to tell "fixed in
next version" and trac could fill out the rest for me.
And finally I forgot to mention:
* bulk edititng of ticket.
We are currently using trac, and we expand it's usage now into
testcasemanagement and requirements management. The above points are
currently some of my findings, where I have additional overhead to get
to my information.
This is no rant, only some ideas, that I would like to see in some future.
Eli Carter
> There are no plugins to my knowledge to provide a UI for customizing
> workflow which is understandable since it's a new feature.
That and I don't have a good idea for what that UI would look like, or how to
do it in a web browser. Suggestions welcome, though implementing it is far
from my highest priority.
Eli
Christopher Taylor
Not familiar with SQLAlchemy, but yes you are correct ... there
ceratinly are a number of circumstances where different types of
tickets should have different fields .... i hope this is comming down
the pipe.
As far as the child ticket issues: to the best of my knowledge, there
are some great things happening with two way linkage of tickets that
will enable really good parent-child relationships. I'm not sure what
release it'll be in .... 0.11 I think.
-Chris
Christopher Taylor
> Christopher Taylor schrieb:
> > this too is possible....... requires a creative use of custom fields
> > and some sql wizadry ....
> >
> Right, but my collegues don't understand why and when they have to fill
> which field with which information.
that gets to the different fields for different ticket types issue
mentioned above.
A custom field that has the source of the bug would work for this ....
you could then specify
source:/trunk/componentname/classfiled@<revision>#L<linenumber>
and then you could write a report for them that takes as input a path
and then searches for all tickets whose aforementioned custom field
begins with the input path
there should be very little user interaction at that point beyond
knowing how to specify a source link in trac.
> > for that one, try a custom field with a trac/code-browser url and then
> > write a query to search based on an input path. (what you would
> > search for is everything that has a prefix of <input>).
> >
> I'm currently looking for a hook script, that will fill out this
> information whith the checkin.
not sure how a hook script can help you here .... you need to know
what lines of code the bug was *found* in. However, this would deff
help you determine what lines of code were modified to fix a bug .....
>
> > don't understand #2
> >
> Our software goes through a lot of version and fixes. We have the normal
> major.minor.revision.buildnumber style for the version number. In most
> cases I can explizitly state in which version/revision a bug was
> introduced, or a feature was missing. Since we service at least two
> releases of our software, I have to fix the same bug at least three
> times, one time in the trunk, and two times in to different releases. If
> I could separate the solution for each release of our software, I could
> close the ticket one time for the trunk and two times for the branches.
>
> Additionally if you could attach a ticket to a revision, e.g. via a
> custom property in subversion, you could easily tell for each branch,
> which tickets are open an which are closed in specific branches.
>
> Currently I have to copy the ticket for each branch, and I have three
> ticket stating the same information.
>
> For me the issue and the resolution is a 1..n relationship.
to me that sounds more like a policy issue than a trac issue. A
suggestion if I may ... use the version number to determine what
version the bug was found in (could be N/A for an anhancement) and
assign it against the milestone for trunk (or the maintenance of a
released version if that's a higher priority for you .... just pick
one and be consistent). Make your changes and then merge them across
branches, only closing the ticket when the changese has been merged
into all appropriate codelines. The implication here is that a ticket
is not closed until it has been merged across all appropriate
codelines. This may save you some headache later on ....
> > #3, don't understand why ... if a milestone is a future version ...
> > where is the problem
> >
>
> if you track hardware and software issues within trac and also customer
> dates, the concept of milestone and "future version" does not mix very
> well. E.g. you must have finished a specific task for a specific
> milestone, but this does not necessarily mean, that this will result in
> a specific version. A bugfix or feature is sheduled for a specific
> future version. A milestone is simply an event, where a few things have
> do be done. Naturally you can use the same concept, but in respect with
> #2, I often want to distinguish between milestone and future version.
our policy is to not have future versions ... we only have milestones
and released versions ... that helps out a lot with the dilema you
describe (we faced that one too). For us, all future versions are
stored as milestones but not all milestones are future versions. This
methodology is of course eagerly awaiting the ability for milestones
to have dependencies.
> > #4, the concept of a version is in there .... what kind of
> > relationships b/n versions are you intending?
> >
>
> 1. version ordering is not identical to natural ordering, e.g. 1.1,
> ...1.9, 1.10, ... and so on.
> 2. The most common use case is: which bugs are fixed in version 1.17.5
> and please list all issues, also the one from 1.17.4, 1.17.3, 1.17.2,
> ... 1.16. In this moment you need to now, which version is the ancestor
> of which version in order to build. Again, everything can be done with
> different queries, but if trac would understand this, it would be
> easier. Additionally, not everybody uses this concept of versioning.
> E.g. one could use names to identify his version. But still one version
> will follow another, and version version is a bugfix release of another.
> and this is an important relationship
> 3. If versions are directly understood by trac, and the ticket is
> assigned to a specific release/version I would be able to tell "fixed in
> next version" and trac could fill out the rest for me.
ahh ... so your talking more about linage rather than versions ....
interesting concept.
your subpoint #3 is address by my above comments about not using
'future versions' and about the imlied task of porting
defects/enchancement across appropriate code-lines. Of course, if you
want to specify what code lines are affected, that makes sense. That
could be solved with a plugin. not a bad idea for a plugin I might
add.
>
> And finally I forgot to mention:
> * bulk edititng of ticket.
> We are currently using trac, and we expand it's usage now into
> testcasemanagement and requirements management. The above points are
> currently some of my findings, where I have additional overhead to get
> to my information.
we are playing around with the same thing ... we created a ticket type
called requirement and a ticket type called test case .... leads to
some good tracability .... combine this with the graphviz plugin ...
sick!!!!
HTH!
-Chris
John M Camara
Here are a few ideas
- the ability to select a predefined workflow template to base a
custom work flow on
- the ability to save a workflow as a template
- leave, new, and closed states should be predefined states
- define actions, their associated permissions, operations, and names
- define custom ticket attributes that are writable or required to be
filled in for a given action. This would also require to move the
action box above the ticket field entry portion of the form on the
ticket template as you would want the user to first select an action
and then see the fields that are writable or required.
- It would be nice if a graphical representation of the workflow was
displayed while the user was modifying the workflow model. This may
require some creative use of Graphviz. Maybe generate SVG and add
some JavaScript. If I have some time this weekend I could experiment
with this to see if this would be doable. It will be interesting to
see how it will be possible to have the output be small enough to
display within a web page while also being readable and better yet if
the user could select the elements in the diagram for editing
properties.
I'm sure there are some items I'm missing but its a start.
John
John M Camara
On Jun 29, 5:34 pm, "Christopher Taylor" <chtay...@gmail.com> wrote:
> John,
>
> Not familiar with SQLAlchemy, but yes you are correct ... there
> ceratinly are a number of circumstances where different types of
> tickets should have different fields .... i hope this is comming down
> the pipe.
>
I was able to hack this into a demo by creating a workflow that was a
combination of workflows defined for each ticket type and adding some
JavaScript on the action radio inputs that would change the form
fields to display based on the transition that would be perfomed for
the selected action.
A couple of dicts were passed into the template that defined the
fields to display based on the current state of the ticket, and dicts
for required/writable vs selected transition.
John
John M Camara
On Jun 28, 10:47 am, David Abrahams
> I'm currently working onhttp://trac.edgewall.org/wiki/TracMultipleProjects/ComprehensiveSolution
> so I have my hands full with another project that companies will care
> about, or I'd help.
>
I can't tell you how many times I could have used this in the past. I
even thought about implementing a solution myself but when I looked
into what would be required to accomplish it, it was just far more of
an effort than I could justify. Is your work following trunk or
based on a previous release?
John
tr...@nogga.de
> A custom field that has the source of the bug would work for this ....
> you could then specify
> source:/trunk/componentname/classfiled@<revision>#L<linenumber>
> and then you could write a report for them that takes as input a path
> and then searches for all tickets whose aforementioned custom field
> begins with the input path
>
Thanks for the tip, I will try this out. Possibly this can be done
automatically with a post-commit hook script??? Need to think about this
a little further.
> not sure how a hook script can help you here .... you need to know
> what lines of code the bug was *found* in. However, this would deff
> help you determine what lines of code were modified to fix a bug .....
>
I thought about parsing a commit message like "fixd bug #xxx introduced
in [1234]" and that together with the checkin path this will
automatically combine the revision with the ticket.
> to me that sounds more like a policy issue than a trac issue. A
> suggestion if I may ... use the version number to determine what
> version the bug was found in (could be N/A for an anhancement) and
> assign it against the milestone for trunk (or the maintenance of a
> released version if that's a higher priority for you .... just pick
> one and be consistent).
That is what we currently do. But it still has the problem, that we can
not tell which bug exist in which version. E.g. if you find a bug in the
trunk, and you can pinpoint the bug to a revision prior to a branch this
bug is also in the branch, until you proof the opposite. This is one of
the nice automatic information you could get out of subversion. Cloning
tickets or having a close policy is only a manual task around organizing
the data. But currently you can not tell from all entered data, which
bugs you can expect in a specific version. Look from a service side. The
service team reports an issue in a specific version of the software. The
develeopment team will assign the issue to a specific revision. From now
on, the service team could query for all known issues in a specifc
version and they will get this information automatically, without
additional human intervention. They would also know automatically,
whether the bug is fixed in this maintenance line or not.
This needs to be combined with the understanding of "linage". I isn't of
a great help to click through all possible predecossors of a version in
order to get the information.
> Make your changes and then merge them across
> branches, only closing the ticket when the changese has been merged
> into all appropriate codelines. The implication here is that a ticket
> is not closed until it has been merged across all appropriate
> codelines. This may save you some headache later on ....
>
This is one workaround for the problem.
> our policy is to not have future versions ... we only have milestones
> and released versions ... that helps out a lot with the dilema you
> describe (we faced that one too). For us, all future versions are
> stored as milestones but not all milestones are future versions. This
> methodology is of course eagerly awaiting the ability for milestones
> to have dependencies.
>
Yes, one milestone can be dependent or include another milestone, e.g
Installation at a customer side will need a specific version of the
software. Milestones also have a workflow behind them, so actually
milestones should be nothing else than another ticket type ;-)
> ahh ... so your talking more about linage rather than versions ....
> interesting concept.
>
Yes, that was what I meant. Sorry for not beeing precise about this.
> we are playing around with the same thing ... we created a ticket type
> called requirement and a ticket type called test case .... leads to
> some good tracability .... combine this with the graphviz plugin ...
> sick!!!!
>
dreaming, if I only could help. But I'm completely booked out with
job/family and my involvement in the vss2svn [1] converter (sorry for
self advertising another open source project ;-) )
Dirk