Thanks for the summary Michael, that’s
very useful. Do you have a reference for this research, or was it internal?
Eugene outlined some key points. To summarize how the interaction
could work in Mylar:
- Activate a task, and build up
a context as you resolve it
- Right click the task in the
Task List and click “Resolve and Commit…”
- A dialog or single-page wizard
pops up that contains:
- A non-editable field displaying
the automatically generated summary, e.g.: bug <id>: <bug
description>
- An editable field for additional
summary information
- An option to attach the task context
to the bug report
- Clicking finish resolves the
report, attaches context if any, and performs the CVS commit
The interesting thing is that attaching the
task context can address point (3) below. If a report is reopened, or you
want to do a code review later on what changed, you would simply activate the
context directly from the bug report. The context contains all of the
interaction history of the report, and can be queried for things like all
changed resources.
Note that everything here is straightforward
to implement other than attaching the context. I think that there is
still an open question about whether bug reports are the best place for storing
Mylar contexts that are intended to be shared with the team, and we’re
prototyping infrastructure for a shared task list and synchronous sharing of
context. But there does need to be a straightforward way to access the
context for a report that has been reopened.
(4) would be nice, and note that in
Monday’s release there is support for Ctrl-clicking bug report references
in Java source because this sort of seamless interaction between reports,
editors, and views is very valuable. But right now it only takes a copy,
click, paste to go from bug ID to an open report, which isn’t bad if this
is not a very frequent interaction.
Mik
From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf
Of Eugene Kuleshov
Sent: August 18, 2005 8:34 AM
To: Mylar developer discussions
Subject: Re: [mylar-dev]
issue-tracking repositories proposal
Michael Valenta wrote:
With regard to repository/bug
system integration, here are some of the possibilities we identified in our
research:
1)
Populate a commit comment with information from a bug (number, title, etc)
2) Commit (or other Team
operations such a branching) triggers change in a bug (e.g. RESOLVED FIXED on
commit)
These two outlined in comments to Mylar's ussue https://bugs.eclipse.org/bugs//show_bug.cgi?id=106862
3) Annotate bug with links to
comitted files for repositories that do not have atomic commits (e.g. CVS).
With repository support the user could then see the exact diff that was
committed.
I wonder how this could be implemented. You'll have to
either scan/index/index entire CVS commit log or attach links to committed
files to bug report (either to server or to local Mylar's copy).
4) Link from a commit comment
to a bug
Outlined in Team/CVS issue at https://bugs.eclipse.org/bugs/show_bug.cgi?id=58646
There are probably other
possibilities but those are the only ones we discussed.
It looks like
there is a need to specify issue tracking repository per-CVS/SVN repository ,
as well as per-project or even per-CVS/SVN module/subcomponent. Second case
would allow to define exeptions for projects that are not using common issue tracking
repository which is a common case on apache CVS/SVN repositories (some of them
are using bugzilla and others - various external JIRA installations).
regards,
Eugene