RE: [mylar-dev] Stand alone bug tracking

["Mik Kersten" <beatmik@xxxxxxx>]

You can now build and use the Task list and Bugzilla together, and
independently of Mylar.  Just check out org.eclipse.mylar: 
- bugzilla.core
- bugzilla.ui
- bugzilla.tests
- tasks
- core
(I updated the instructions at: http://eclipse.org/mylar/dev.html)

Since they've evolved together from the beginning decoupling these turned
out to be a big job, and we still have a few bugs to fix tomorrow.  We also
get rid of the Mylar glasses showing up in the table tree.  But all issues
should be resolved by Firday's 0.3.2 build.  But you should get a rough
idea, and I'll ping the list when these are done.  Let me know if you are
able to work with the sources and the plug-ins, and let's synch up soon on
how best to proceed.

Cheers,

Mik

> -----Original Message-----
> From: Mik Kersten [mailto:beatmik@xxxxxxx]
> Sent: Tuesday, July 12, 2005 10:35 PM
> To: 'Mylar developer discussions'
> Subject: RE: [mylar-dev] Stand alone bug tracking
> 
> Thanks for posting this summary Jeff.  I used to use the Platform/Team
> plug-in, thought it was an elegant solution, and like where you've taken
> it.  Comments inline.
> 
> > -----Original Message-----
> > From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-
> bounces@xxxxxxxxxxx]
> ...
> > It seems to be accepted that both the Mylar bug tracker and the stand
> > alone bug tracker can share a back end model, but the front end could
> > take any one of a number of approaches:
> >
> > A: have the Mylar Tasks plug-in as the main view for a stand alone bug
> > tracker.
> 
> This is now possible regardless of the back-end.  The Tasks plug-in has
> been de-coupled from Bugzilla, and Bugzilla simply makes contributions to
> it to add Bugilla tasks, query categories, UI actions, a cache for editing
> them, etc.  This was done partly to open us up to the option of supporting
> multiple issue tracking systems.  It also had the effect of splitting out
> the back end into org.eclipse.mylar.bugzilla.core so to enable using that
> as a common back-end without forcing the use of our current UI.
> 
> > B: have a common (bug) back end for the Bug tracker and for Mylar but
> > have different UIs (Mylar tasks view for Mylar and the Platform/Team UI
> > for stand alone)
> 
> I think that we need ensure that this is an option going forward.  Even if
> the Mylar team were partial to the Tasks plug-in, the Eclipse community
> could decide that they like the Platform/Team one more, or some entirely
> new offering.  So theoretically we now support any task management system
> enabling/disabling task contexts via Mylar Core without coupling to the
> Mylar UI, Bugzilla, or Tasks plug-ins.
> 
> > C: integrate the platform/team UI as the main bug view in Mylar (and use
> > it for both Mylar and stand alone)
> 
> This will be possible, as mentioned above.
> 
> > D: Pull features from both bug UI's and build something new, though one
> > would likely serve as the basis.
> 
> I could see that as more of a long-term possibility.  In the short term
> Mylar depends very heavily on high-quality bugzilla integration and task
> management, which is why we have been sinking so much time into it.
> 
> > E: something entirely different... (?)
> 
> Before figuring out how to proceed, I think that it would be great if you
> could give the newly separated Tasks and Bugzilla plug-ins a whirl, so
> that we could identify where the overlap is and what to build on.  We'll
> have documentation on the Tasks plug-in in the Friday release, but for now
> I'll just go through your points
> 
> > Here's a quick summary of the current state of eclipse-bugzilla (from
> > memory, hopefully I don't miss too much ;)
> >
> > o Presentation (UI).
> >   . Create folders, dnd organization
> 
> We support a task list that can have tasks and bug reports in the root, in
> categories, and in query categories (very similar to the Platform/Team
> queries).  Drag and drop, TreeTable columns editing, and all those UI
> things work.  Filters for priority and completion are supported.  We have
> support for sub-tasks, but it's turned off because most people have enough
> trouble managing categories and it makes the task lists start looking
> hairy.
> 
> >   . Handles any number of bugzilla providers
> 
> This is currently a key limitation of ..mylar.bugzilla, but not too hard
> to address.
> 
> >   . Allows custom names of elemtents (ex. queries, folders)
> 
> Yup.
> 
> >   . "quick view" shows info about selected elements and auto
> >     hides when not needed
> 
> We rely on the Outline and bug editor for this.
> 
> >   . Integrated query dialog has "simple" and "advanced" modes.
> 
> Don't have this, since we optimized around having a single Eclipse Search
> based dialog (seamless Eclipse our driving design goal).  But I like the
> way yours turned out.
> 
> >     Organizes options into tabs to avoid the cluttered presentation
> >     often associated with bugzilla query pages.
> 
> This seems like it could be nice too.  The are just so many Bugzilla
> search options to set that any single dialog gets overwhelming.
> 
> >   . Bugzilla Browser, embedded browser can be launched to show
> >     selected elements.
> 
> This works now too.  It's actually the default setting now, until our Bug
> Editor becomes more feature complete.  But note that we store log-in
> credentials in ..bugzilla.core so you don't have to do that repeatedly.
> 
> >   . misc nicities (grabs icon associated with bugzilla db for view,
> >     actions for elements displayed in context menu)
> 
> The notable thing here is that the Task List allows action contributions.
> But you'll notice that these aren't extension points yet, and should be.
> 
> > o Functional bits
> >   . Attachment handling (Apply Patches directly to a workspace,
> >     view logs (or other text/*) in the quick view, show attachments
> >     in the bugzilla browser)
> 
> Another key limitation of ours.  I *really* like the idea of applying
> patches directly to a workspace.  It would be so neat if we could drag
> patches from a Bugzilla editor to a project...
> 
> >   . Integrated "read" operations in bugzilla (querying, viewing bug
> >     info, downloading attachments, etc..). No operations that
> >     modify the db are integrated, awaiting bugzilla WebService.
> 
> Via the bug editor.
> 
> >   . Bugzilla Browser: web browser for viewing the actual bugzilla
> >     pages. DB modifying operations can be performed from here.
> 
> Via either bug editor or internal browser.
> 
> >   . Persistent bug management/organization.
> 
> We serialize the task list as 'readable' XML, and all the view
> configurations get IMemento'd.  We have a cache of reports, and also
> support working with cached reports offline so that you can synch when
> you're connected again (and do a diff).  The cache is also used for our
> search support, which gets pretty fancy with Mylar in the loop (it does
> active searches of the bug repository in the background).
> 
> >   . Support for bugzilla 2.16 -> 2.18
> 
> Got that, configurable via preference option.
> 
> > o Misc.
> >   . Code base originally developed by Platform/Team, now actively
> >     developed by redhat.
> >   . Currently only one committer/project maintainer (Jeff Pound)
> >   . Have received patches, bug reports, emails, and general
> >     interest from people at ibm, redhat, and others. (Ed Burnette
> >     has also contributed a couple patches)
> >   . Currently ships with Fedora Core 4 (natively compiled with gcj)
> >   . Targeted as java 1.4.2 / Eclipse 3.1 compliant code.
> >   . Installation / CVS details here http://people.redhat.com/jpound
> 
> We'll review your sources tomorrow.  By tomorrow afternoon/evening I'll
> reply this message to let you know that the de-coupled Tasks and Bugzilla
> plug-ins are ready to be tried out.  The let's synch up again and figure
> out how best to proceed!  It seems that there should be a natural way for
> us to combine efforts...
> 
> Best regards,
> 
> Mik
> 
> --
> http://kerstens.org/mik