Good point, Tom. I actually went down another path - one I would for which I would love to have a good "open" solution. Suppose I had to Bugzilla repositories. One where I maintained my internal defects while the other where I maintained customer facing defects. I even would want the customer to have access for submissions and reporting. While working on tasks, having the customer task in context, and which ever internal tasks in context would be great. I see Carole's question as a special case of a more general problem, though. In my situation, the relationship between tasks in two repositories would represent an n-to-m relationship rather than 1-1. In the past, I've implemented this through back-end solutions, where the n-to-m relationship was maintained behind the scenes rather than in Mylyn; however, having multiple contexts is very useful, IMHO.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tom Bryan (tombry) Sent: January-24-09 6:26 PM To: Mylyn Integrators list Subject: RE: [mylyn-integrators] Multi bugtrackers project Randall S. Becker wrote on Saturday, January 24, 2009 3:32 PM: > whether two tasks can share the information. One difficulty I see with the later is > that only one active context is permitted. Right. I've actually been thinking about that lately. I can see some benefit in having multiple active tasks at once. It's currently an enhancement: https://bugs.eclipse.org/bugs/show_bug.cgi?id=217315. For example, maybe a company uses Bugzilla for customer "problem reports" but Trac for development tasks/bugstracking. In this case, some bugs may live in two places: in the customer-facing system and the internal system. A customer reports a bug, it gets an entry in the Bugzilla repository. When development reproduces it, they create a bug in Trac for the task. It may make sense to associate the same context to both the Bugzilla task and the Trac task at this point. Or a more realistic example. The two systems may be the bug tracking system (e.g., Bugzilla) and the task/project management system (e.g., Rally). Perhaps there are several Rally tasks to fix one Bugzilla task. In this case, I may want to activate the Bugzilla bug and Rally task1. Then, I finish the first chunk of work and use the Rally task1's context to commit/review the code. Now I work on Rally task2, but I still want the same Bugzilla bug to be active at the same time. So, eventually, the Bugzilla bug's context would be similar to the union of the context from the associated Rally tasks. I assume that this latter example is the more difficult. For example, in the context of the Bugzilla bug, I may have viewed a file 3 times, but in the context of the Rally task2, I have never visited the file. Or I only visited it once. Or maybe I actually modified a file in the context of the Bugzilla bug, but in the context of the Rally task2, I have only viewed the file once. I'm not sure whether the benefit of being able to have multiple active tasks at once is worth the added complexity to the code and to the user-visible behavior of Mylyn, but I guess I should add this scenario to that bug. -- Tom Bryan <[email protected]> Cisco Systems RTP, NC, USA _______________________________________________ mylyn-integrators mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/mylyn-integrators _______________________________________________ mylyn-integrators mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/mylyn-integrators
