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

[Eugene Kuleshov <eu@xxxxxxxx>]

Mik Kersten wrote:

  Thanks for the response Mik.

Sorry, by “common” I meant frequently used, not standard or better. But just to be clear: Mylar currently has no dependencies on CVS or any other repository system.  You should be able to use it with any repository.  There’s the enhancement request to make “Resolve and Commit” work which will require awareness of the repository system, but when we do that we’ll make sure that it is easy to extend to something like subclipse.

   I know that it is very clean in terms of isolation, but is also doesn't allow to integrate with anything else at the present moment. Again I know that it will be there eventually, but I guess I just can't wait. :-)

I am sorry about your frustration with not being able to use multiple providers.  The reason that we don’t integrate with the Team/Bugzilla plug-in is that we have different internal models of bug reports and queries, and we came to a conclusion with Jeff Pound that it would be best to merge these. 

  That would be the best option.

I really hope that over the next few weeks we can resolve this issue and support you better.  I’ll post some discussion on how we could proceed next week after we’ve had a chance to look at the 1.4 issue, since Jeff requested that this be addressed.  Regarding your suggestion, yes, it is feasible for us to make an optional plug-in that would extend the Team/Bugzilla plug-in to put those repositories’ content into the Task List, but I hope that work can be avoided by us sharing a common core.

   Suggestion was to replace it and move Mylar's bugzilla implementation into issue tracking plugin that Jeff is working on or/and merge it with Jeffs plugin sometime later.

  regards,
  Eugene

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

_______________________________________________
mylar-dev mailing list
mylar-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylar-dev