Mylar Issue Tracker Requirements
History
- 2005-11-25: Initial draft (Brock Janiczak and Mik Kersten)
General
- 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?
- Consider the case of a user that is new to a project. It would be really nice if all they had to do was check out a project from CVS/SVN and the tracker instance is created and associated with the project automatically. I was expecting to store this information as a project scoped preference (so it can be checked in to version control). Another option is to have a a file (like the team PSF file) that can be imported to create the required tracker instances and attempt to connect each project to its appropriate instance.
- Also, most issue trackers have some way to partition bugs into groups (that can relate to a project atrifact). It would be nice if this could also be associated with the project so when an issue is created in the context of a project the component (or whatever your tracker calls it) can be defaulted.
- No coupling to mylar core or UI.
Queries
- 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.
Text
- 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?
- It is possible to open a resource directly from the history view or the repository view. In these cases there is no 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.
- A popup action is fine when there is only one bug referenced in the commit comment, but some people (like myself) sometimes check in a change that relates to multiple issues. I probably shouldn't, but i do :)
- Populate commit comment with issue details.
- Brock: (Possible use the new template stuff? Ie a dynamic template)
- Just clarifying this as it makes no sense at all... In 3.2 CVS supports static templates. The user just creates a chunk of text and it can be added into the commit dialog. I can't see why this template support can't be updated to support 'active' templates. You select a 'bug' template and a dialog pops up asking you to enter (or search for) a bug. These values will then be inserted into the template before it is added to the commit dialog. I think this would be of more value than the current static templates. I would be willing to look at providing a patch to Team/CVS for this one. btw, I will try and convince them to push it down to the Team level so the same templates can be used for all team providers (it seems to make sense).
- 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.
- again, what was I on? I basically wanted a post commit hook so we could perform an action against the issue tracker. The obvious thing to do is comment/resolve an issue. Perhaps i was asking for a team level commit dialog???
Mylar
- 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.
- I am not sure how to support
local issues yet. It is almost as if we need another
view to show local issues (the platform task view would
be perfect)
- I have been thinking about the best way to structure the UI. The issue tracker as it currently stands is no good. I was considering having two separate views; A "Repository browser" and an issue list. The common navigator stuff that is coming for 3.2 would be perfect for the repository browser. We could have a top level (project level) item for the issue trackers as well as a node in each project that has an attached provider. This seems to be a more logical thing to do and puts the issue information right where the user needs it.
Use Cases
- Work with bugs and queries within Eclipse.
- Work with Mylar's task contexts (layers on above).
- As a user, one thing i would *love* is to have a list of active searches. These will update every so often and let me know when there are new matches (or changes). This way i don't have to be distracted by emails. Being able to switch between a set of issues without re-running the query would also be nice.