[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[Fwd: Re: [mylar-dev] issue-tracking repositories proposal]
|
Mik Kersten wrote:
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:
o A non-editable field displaying the automatically
generated summary, e.g.: bug <id>: <bug description>
o An editable field for additional summary information
o 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
It is really cool up to the last point. Unfortunately CVS is only
popular in open source projects and even there it is loosing to
Subversion. So, what if user have SVN, or Perforce or some other XYZ
version control system?
Subclipse - http://subclipse.tigris.org <http://subclipse.tigris.org.>
Clearcase - http://sourceforge.net/projects/eclipse-ccase and
http://www-128.ibm.com/developerworks/rational/library/content/03July/2500/2834/ClearCase/clearcase_plugins.html
Darcs - http://eclipsedarcs.org
SourceSafe - http://esstp.sourceforge.net and
http://sourceforge.net/projects/vssplugin
p4eclipse - http://sourceforge.net/projects/p4eclipse/
Complete list is at
http://eclipse-plugins.2y.net/eclipse/plugins.jsp?category=SCM
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.
Actually it will also require to find out what issue repository you
should go after.
This Mylar limitation is a real showstoper at the present moment. Unless
I'm missing something.
regards,
Eugene
------------------------------------------------------------------------
*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
<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