RE: [mylar-dev] Stand alone bug tracking

["Mik Kersten" <beatmik@xxxxxxx>]

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