Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

Mylar Issue Tracker Requirements

Revision as of 00:31, 25 November 2005 by Mkersten (Talk | contribs) (Mylar Issue Tracker Requirements (draft) moved to Mylar Issue Tracker Requirements)


  • Initial version (Brock Janiczak and Mik Kersten)


  • Associate a repository with a project, credentials stored in keyring. UI is a project properties page specified by provider.
  • Possibly provide view showing all repositories, where each provider can populate repository nodes with contets (e.g. products, reports).
  • Should be able to discover new repositories by checking out a project.
    • Mik: Brock, could you provide more detail on this one?
  • No coupling to mylar core or UI.


  • Provide a general notion of a query and parameters, hits returned, and a persistance mechanism (a first cut at this is already in mylar.tasklist).
  • Provide incoming/outgoing status notification.

Editing Reports

  • Basic mode of embedding browser when opening issue.
  • Generic issue editor similar to Mylar's Bugzilla one, based on attributes and comments.


  • Hyperlink issue number in text editors.
    • Brock: Berhaps we could have Team support for this? SVN could store the info in properties and CVS in a file.
    • Mik: isn't it enough just to look up the repository associated with the project?

Source Repositories

  • Provide hyperlink support in the history view
    • Mik: This may be better as a popup action, which Mylar already has. But hyperlink could work as well.
  • Populate commit comment with issue details.
    • Brock: (Possible use the new template stuff? Ie a dynamic template)
  • Perform some sort of Issue workflow action on commit (probably resolve)
    • Brock: CVS has no support for any of this yet. They would probably accept patches for most of this. If some of this could be moved to Team, even better. All repositories have a commit process and all have a revision history.


  • What are the requirements for Mylar?
    • Brock: It really only needs to get a list of issue from a query. The query implementation and UI need to be provider specific unless the query is always "my bugs". I don't see a problem with adding a Mylar/Issue Tracker bridge to do this.
    • Mik: The main thing Mylar needs is for there to be a single high quality Tasks view that makes it easy to work with local tasks, reports, and queries, and for that to be consisntent across providers. What it layers on to that is the ability to activate contexts. It also needs a mechanism for attaching context to issues, and retrieving them from issues. From a source and feature perspective the task functionality should be decoupled from Mylar (and it is, i.e. you can use the Mylar Tasks view and Bugzilla support without the Mylar UI). But Mylar is all about a very task-centric view of the world, and as such the UIs will be highly interdependent.

Use Cases

  • Work with bugs and queries within Eclipse.
  • Work with Mylar's task contexts (layers on above).

Back to the top