Sorry, I meant research in very loss
terms (i.e. we developed the original prototype and had some discussions
about what might be possible). There is no supporting documentation. As
for your comments on where to store the Mylar context, I have had conversations
about this with others and the conclusion was that you probably don't want
to store it in Bugzilla since it only has meaning from inside Mylar. It
would probably be better for Mylar to provide a link from a bug to the
context which is stored using another means (perhaps in CVS;-).
As for the commit scenario you describe,
you could probably do it using the CVS CommitWizard class. All you really
need is the ability to trigger the wizard (which already exists but in
non-API form) and the ability to prime the comment (this isn't there but
shouldn't be a large modification). You may also need to get some return
code from the wizard to indicate the result sof the commit (again, you
would probably need to add this).
Michael
"Mik Kersten"
<beatmik@xxxxxxx> Sent by: mylar-dev-bounces@xxxxxxxxxxx
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).
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 _______________________________________________
mylar-dev mailing list
mylar-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylar-dev