From: mylar-dev-bounces@xxxxxxxxxxx
[mailto:mylar-dev-bounces@xxxxxxxxxxx] On
Behalf Of Eugene Kuleshov
Sent: August 18, 2005 9:30 PM
To: Mylar developer discussions
Subject: Re: [mylar-dev]
issue-tracking repositories proposal
Mik Kersten wrote:
As Eugene indicates, Mylar’s goal
is to make it easy to manage task context, so we are focusing on abstractions
for manipulating context and trying to do as little defect/source repository
work as possible until we grow the number of committers. Our goal for the
user study releases is to make sure that Mylar works well for a common Eclipse
configuration (Bugzilla, CVS).
I wonder where this assumption about common
configuration came from? If you look at one of the oldest open source factory -
Apache - it is migrating projects from CVS to SVN and many of Apache projects
are using JIRA as a bug tracking system. SF, Tigris, java.net provide both CVS
and SVN. Subclipse got much better in a last few months and it is sad that it
wasn't developed in Eclipse house.
In commercial software development situation is even worse - dev teams
has to use the company standards and you rarely see SVN or even JIRA there.
After playing with Mylar for a few weeks I really frustrated that I
can't use it for my day job because I can't plug in custom issue tracking
repository provider. As you said, Mylar is first of all about tasks, so it is
most important to get task flow coming in, otherwise the use is limited.
Why couldn't Mylar just pickup Bugzilla plugin extension points and use
repositories registered there?
But as soon as someone signs up for
extending Mylar to another system, e.g. Subversion, we will actively support
them and by doing so turn those abstractions into API and extension points.
Prompted by Jeff Pound we have started this for the Task List, which now
has extension points for adding new kinds of categories and tasks (no common
query support yet, but that won’t be too hard).
I'll forward this to Subclipse dev list, but
there is also shortage of the committers.
So for things like the Resolve &
Commit wizard we will keep in mind that it should be generic, but as Michael
points out it won’t actually be generic until there is a second driver.
But anything generic that we implement in order to enable more seamless
interaction with tasks and context (e.g. https://bugs.eclipse.org/bugs/show_bug.cgi?id=58646)
we will be happy to contribute to Platform/Team as patches.
Subclipse can be a
second driver. However linking bug tracking integration is a secondary task, so
I believe it is a highest priority to define common integration points and get
an infrastructure for plugging in custom issue repository providers.
regards,
Eugene