OT : Bug/Issue tracking systems

Discussion in 'VHDL' started by moogyd@yahoo.co.uk, Dec 17, 2006.

  1. Guest

    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
     
    , Dec 17, 2006
    #1
    1. Advertising

  2. Hi Steven,

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

    Utku.

    wrote:
    > 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==?=, Dec 17, 2006
    #2
    1. Advertising

  3. writes:

    > 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
    --
    Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
     
    Kai Harrekilde-Petersen, Dec 17, 2006
    #3
  4. Guest

    Kai Harrekilde-Petersen wrote:
    > writes:
    >
    > > 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
    > --
    > Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>


    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
     
    , Dec 17, 2006
    #4
  5. writes:

    > Kai Harrekilde-Petersen wrote:
    >> writes:
    >> > 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.

    >
    > 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
    --
    Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
     
    Kai Harrekilde-Petersen, Dec 17, 2006
    #5
  6. Guenter Guest

    wrote:
    > 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
     
    Guenter, Dec 19, 2006
    #6
  7. Hi Guenther

    "Guenter" <> writes:

    > 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
     
    Marcus Harnisch, Dec 20, 2006
    #7
  8. Guenter Guest

    Marcus Harnisch wrote:
    > 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
     
    Guenter, Dec 20, 2006
    #8
  9. "Guenter" <> writes:

    > Marcus Harnisch wrote:
    >> However, in general, if you using SVN for revision control, it is
    >> better to have one repository per project:

    >
    > 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."

    --
    The Germans have inherited a filthy Saxon culture and no more need be
    said about them.
    -- Mark Ballard, The Register
     
    Marcus Harnisch, Dec 21, 2006
    #9
  10. Jeremy Ralph Guest

    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
     
    Jeremy Ralph, Jan 2, 2007
    #10
  11. "Jeremy Ralph" <> writes:

    > 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:

    Marcus Harnisch writes:
    > 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
     
    Marcus Harnisch, Jan 5, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. PontiMax

    Recommendable bug tracking software?

    PontiMax, Nov 17, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    412
    Steve Haun
    Nov 17, 2003
  2. Guest
    Replies:
    2
    Views:
    484
  3. Rick DeBay
    Replies:
    4
    Views:
    507
    Dmitry R
    Dec 31, 2003
  4. Mike
    Replies:
    2
    Views:
    668
  5. Replies:
    4
    Views:
    327
    Phil Schmidt
    Dec 17, 2006
Loading...

Share This Page