OT : Bug/Issue tracking systems

[moogyd]

Hi,

(Off-topic, Cross-posted to comp.lang.vhdl and comp.lang.verilog)

I am looking to put an open-source bug/issue tracking system in place
for our current project (eventually expanded for all projects), and
would appreciate any experiences/comments/suggestions.

I am also going to solicit suggestions on a couple of S/W groups, but I
really need comments from a ASIC/ASSP design flow perspective.

The easiest method is using a spreadsheet, but this is not very
expandable.

The requirements I have come up with

- Free ;-)
- Easy to setup and maintain (I want this to be an engieering tool, not
an IT project)
- A non linux expert should be able to download and install (rpms OK,
deep understanding of makefiles and linux kernel not OK)
- Ideally via text files, a bit of perl/tcl/etc OK. I'd rather avoid
SQL
- Prove the system and then hand-off to IT for maintenance
- Easy use
- Browser UI
- Mail ?
- Linux
- Flexible reporting/search
- User/admin accounts
- Initially internal network access only, eventually external
(customer, partner) access
- Cover HDL, H/W, F/W, Documentation, Change requests. Both ASIC and
FPGA.
- Eventually production issues (Yeild, Test programs?)
- Maybe allow project deadlines included.
- We use CVS, so any loose coupling useful
- We have per project repositories, plus and repository containing
common IP's (i.e a project will always use 2)
- Medium size projects (upto 15-20 people
- Possible migration to other system in future (which I guess means a
well supported database)

Googling provided with lots of names
- Bugzilla (seems to be in widest use for S/W projects)
- GNATS (I recall using this in a previous job)
- IssueTrackerSystem (ZOPE, Python)
- Trac (Python)
- Plus lots of others

Any suggestions, comments, recommendations or pointers to
papers/tutorals greatly appreciated.

Steven

 

[=?iso-8859-1?B?VXRrdSDWemNhbg==?=]

Hi Steven,

check out Mantis (http://www.mantisbt.org). It does exactly the one you
are looking for.

Utku.

 

[Kai Harrekilde-Petersen]

Hi,

(Off-topic, Cross-posted to comp.lang.vhdl and comp.lang.verilog)

I'd say this is at least semi-on-topic.

I am looking to put an open-source bug/issue tracking system in place
for our current project (eventually expanded for all projects), and
would appreciate any experiences/comments/suggestions.

Consider carefully whether you expect to develop IP cores that are
going to be used in multiple chips. If you do, consider using a tool
where you can have a hierarchy of issue groups, so that you can
submit, track, and close independently an issue with IP block <foo> in
multiple chips at the same time.

I have used Gnats in a previous job, and we had to break our own and
gnats' back to get this to "work" (much manual work in selection,
copying, and tracking of the original issue was needed).

Now imagine that you have ~5 basic IP blocks and 3 different chip
architectures, which were reused across 15-20 tapeouts within 5-6
years and you are starting to get a LOT manual checking and
crosschecking between issues in different chips to figure out whether
a particular issue really applies to what you're taping out.


Kai

 

[moogyd]

I'd say this is at least semi-on-topic.


Consider carefully whether you expect to develop IP cores that are
going to be used in multiple chips. If you do, consider using a tool
where you can have a hierarchy of issue groups, so that you can
submit, track, and close independently an issue with IP block <foo> in
multiple chips at the same time.

I have used Gnats in a previous job, and we had to break our own and
gnats' back to get this to "work" (much manual work in selection,
copying, and tracking of the original issue was needed).

Now imagine that you have ~5 basic IP blocks and 3 different chip
architectures, which were reused across 15-20 tapeouts within 5-6
years and you are starting to get a LOT manual checking and
crosschecking between issues in different chips to figure out whether
a particular issue really applies to what you're taping out.


Kai

Hi Kai,

We do have IP's that are used in multiple chips, and so this will be in
issue.
It sounds llike it is not easy to do with Gnats. Are you aware of a
tool that handles it better?

Thanks,

Steven

 

[Kai Harrekilde-Petersen]

We do have IP's that are used in multiple chips, and so this will be in
issue.
It sounds llike it is not easy to do with Gnats. Are you aware of a
tool that handles it better?

Alas, I am not aware of a tool that does this (but I haven't looked
for it either). However, it should be relatively straight-forward to
design and implement.


Kai

 

[Guenter]

Hi,

(Off-topic, Cross-posted to comp.lang.vhdl and comp.lang.verilog)

I am looking to put an open-source bug/issue tracking system in place
for our current project (eventually expanded for all projects), and
would appreciate any experiences/comments/suggestions.

[...]

I am working with Trac and SVN. At the moment having a separate
repository for each project and one repository for company stuff,
including documents, IP, and software tools. For each repository there
is a Trac instance.

After several month of experience I would tend now to one SVN
repository and one Trac instance for all. Putting a subbranch for each
project and the company stuff, there is still a division of projects
possible. Having one instance of Trac has the advantage that all
tickets are in one data base and this would get rid of the problem
having to search through several different ticket data bases. That has
also the advantage that one user can search very quick, what tickets
are there for him/her over all projects.

So basically I would setup a project structure in SVN and also adjust
Trac to have an additional project property for tickets. That way it
would be possible to categorize tickets per project, but also add for
example keywords that include the IP this ticket affects. That way it
is possible to search for tickets per IP across the projects.

Cheers,

Guenter

 

[Marcus Harnisch]

Hi Guenther

After several month of experience I would tend now to one SVN
repository and one Trac instance for all. Putting a subbranch for each
project and the company stuff, there is still a division of projects
possible. Having one instance of Trac has the advantage that all
tickets are in one data base and this would get rid of the problem
having to search through several different ticket data bases. That has
also the advantage that one user can search very quick, what tickets
are there for him/her over all projects.

Not having used Trac I obviously cannot say how it interacts with the
revision control system. However, in general, if you using SVN for
revision control, it is better to have one repository per project:

1. Easier to migrate individual projects to an different server.

2. It is, in fact, easier to maintain a family tree of projects and
sub-projects using external references to other repositories than
using an in-tree file system based hierarchy.

3. Should a database corruption happen, it is far less likely, that
projects in other repositories are affected.

4. Projects have different demands when it comes to hook-scripts. Yes,
you could solve that with a single-repo layout, but it is messy.

No bashing intended, but if the issue tracker cannot deal with
hierarchies of multi-repo projects, you should start looking at
alternatives.

Regards
-- Marcus

The Germans have inherited a filthy Saxon culture and no more need be
said about them.
-- Mark Ballard, The Register

 

[Guenter]

Hi Guenther [...]
Not having used Trac I obviously cannot say how it interacts with the
revision control system. However, in general, if you using SVN for
revision control, it is better to have one repository per project:

1. Easier to migrate individual projects to an different server.

2. It is, in fact, easier to maintain a family tree of projects and
sub-projects using external references to other repositories than
using an in-tree file system based hierarchy.

3. Should a database corruption happen, it is far less likely, that
projects in other repositories are affected.

4. Projects have different demands when it comes to hook-scripts. Yes,
you could solve that with a single-repo layout, but it is messy.

No bashing intended, but if the issue tracker cannot deal with
hierarchies of multi-repo projects, you should start looking at
alternatives.

Thanks Marcus for sharing that.

Good points about looking at the SVN side.

So the best way would be if Trac would be able to handel different
repositories, looking at it from the point of having one ticket data
base. But then I guess you could say similar things about the issue
data base. Only that it probably will not growth to such an extend as a
project repository.

Cheers,

Guenter

 

[Marcus Harnisch]

But then I guess you could say similar things about the issue data
base. Only that it probably will not growth to such an extend as a
project repository.

He, He. I suppose you could say that indeed. But the usage patterns of
revision control and issue tracker can be very different. For
instance, you don't want to log into several issue trackers just to
check what has been put on your plate today.

An ideal issue tracker would provide a common portal page (assuming it
is www-based) and connect you with a (number of) database(s). That
issue tracker would also have to provide a way to cross-reference all
associated databases (possibly locally distributed). It must be
possible to submit queries to (a group of|all) databases.[1]


Regards,
Marcus

Footnotes:
[1] "Today is clock fixing day. Show me all issues in all projects
that have clocking issues."

 

[Jeremy Ralph]

I would recommend Bugilla as it is free, robust, and quite flexible.
Don't be tempted to try and build your own when there is so much
already available and I would assume your time is better served on your
product.

You can customize Bugzilla to list your specific Products, then for
each product you have Components, Versions, and Target Milestone's.
Keywords allow another interesting dimension for customization. For an
SoC development paradigm I'd consider having each IP block as its own
product (IP-Product), maintained independent of the device product
(Dev-Product). Then for each Dev-Product have a component for each IP
instance which can reference to the IP-Products' bugs by # or URL.
You'd probably want to create a users-guide for how your team will
apply a reuse-based methodology around Bugzilla and prepare an example
deployment to prototype your flow.

Regarding source control I would mirror Marcus's statements except that
I would have a repository for each project but also a repository for
reusable IP which would live independent of the projects. Then use the
externals capabilities of SVN (see
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-7-sect-3) or a
scripting layer over CVS, to pull in the reusable IP blocks by version.
A layer of scripting over the source control makes this easier and
ensures everyone follows your specific procedures.

In the software world, I've heard of projects requiring that every CVS
or SVN committal be associated with a least one bug report (or tasks as
I prefer) -- this sounds like a good idea to me.

A couple of other tidbits on Bugzilla: Milestones are good for planning
into the future and associating work-tasks (i.e. bugs) to specific
milestones. Mylar (http://www.eclipse.org/mylar/) is an interesting
Eclipse plugin for interfacing with a Bugzilla database and scheduling
tasks, unfortunately I don't think the context stuff would work for
Verilog / VHDL files, but it could be adapted for this some-day which
would be awesome [Mik are you listening?]. With Bugzilla, mysqldump
can be used to backup the database on a regular basis using a cron job
(or win equiv). Bugzilla can be a pain to setup but is probably one of
the most useful open source projects out there and once it's setup it's
rock solid.

I'd be happy to help / discuss further, drop me a note at
http://www.productive-eda.com/contact-PDTi if you like.

Regards,
Jeremy

---
PDTi :: Simplifying standards-based ESL specification & implementation
http://www.productive-eda.com

SpectaReg :: Register-Map Productivity Made Simple.
http://www.productive-eda.com/spectareg

 

[Marcus Harnisch]

Regarding source control I would mirror Marcus's statements except that
I would have a repository for each project but also a repository for
reusable IP which would live independent of the projects. Then use the
externals capabilities of SVN [...]

Which is pretty much what I said here:

2. It is, in fact, easier to maintain a family tree of projects and
sub-projects using external references to other repositories than
using an in-tree file system based hierarchy.

External references are extremely simple and powerful.

In the software world, I've heard of projects requiring that every CVS
or SVN committal be associated with a least one bug report (or tasks as
I prefer) -- this sounds like a good idea to me.

Some SVN GUI interfaces (e.g. Tortoise SVN) support that requirement
via Subversion attributes (look for the bugtraq:* attribute
specification). Good thing about that is that you can have this policy
a strict requirement in your stable branch, while you can loosen up a
little in development branches.

Regards,
-- Marcus