From:
mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael Valenta
Sent: August 18, 2005 10:50 AM
To: Mylar developer discussions
Subject: RE: [mylar-dev]
issue-tracking repositories proposal
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
18/08/2005 01:27 PM
|
Please
respond to
Mylar developer discussions
|
|
|
To
|
"'Mylar developer discussions'"
<mylar-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [mylar-dev] issue-tracking repositories
proposal
|
|
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
_______________________________________________
mylar-dev mailing list
mylar-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylar-dev
