Re: [mylar-dev] issue-tracking repositories proposal

[Eugene Kuleshov <eu@xxxxxxxx>]

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