RE: [mylar-dev] Stand alone bug tracking

[Jeff Pound <jpound@xxxxxxxxxx>]

On Wed, 2005-07-13 at 20:30 -0700, Mik Kersten wrote:
> 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.
> 

Hi Mik,

I tried out Mylars bug tracking support. There is a lot of overlap with
the eclipse-bugzilla plug-in and some complimentary features as well.
>From a high level functionality viewpoint, there is plenty of room for
collaboration. But this is now secondary to my main concern. The first
thing I noticed about Mylar is that it depends on Java 1.5, this is a
problem for both my interests (deploying with a non-proprietary java
stack such as gcj), and from the general viewpoint of eclipse 3.1
integration. Eclipse 3.1 requires java 1.4. There have been no official
announcements that I know of, but the general consensus of some news
group discussions was that eclipse would support compiling java 1.5, but
the platform itself would retain java 1.4 compliance.

I'm not quite sure how to proceed from here. I would have no problem
contributing to a java 1.5 spec when free java support for 1.5 is
available (I guess it's not really unreasonable for a plug-in to require
java 1.5 despite the platform staying at 1.4), however until then I
can't really contribute my time as this project will not be deployable
on fedora's free java stack. Sorry :(


Jeff




> 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
> 
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev
-- 
Jeff Pound <jpound@xxxxxxxxxx>