[Libreoffice] [REVIEW] Oracle Report Builder corrupting chart objects

Michael Meeks michael.meeks at novell.com
Tue May 17 02:24:55 PDT 2011


Hi Kohei,

On Mon, 2011-05-16 at 22:14 -0400, Kohei Yoshida wrote:
> 1. Promote the chart8 filter as the preferred filter for the
> chart2.Document type.  This can be done by the attached
> chart8-is-preferred-for-chart-document.diff patch.

	Patch looks great to me :-) can we get that into -3-4 and get some more
reviews for -3-4-0 ?

> 2. Remove the type detection definition for the chart2.Document type
> from the report builder itself.  This can be done by the
> report-builder-dont-act-like-chart-handler.diff patch.  This will
> prevent ORB from advertising itself as the chart filter provider.

	Did you manage to play with the ORB chart feature ? I would strongly
prefer a potential, transient breakage there, than an ODF
incompatibility that will create broken files when we save ;-)

> I think option 1 is pretty safe, but I don't really know if this would
> cause any side effect in other, unexpected places.  For instance, the
> latest ORB seems to claim some limited charting functionality, and this
> may mess that up, or perhaps it may not.

	Well - it sounds like the ORB is pretty messy anyway :-) so ... can it
really make it much worse if it crashes the whole app left and right ?

> My preferred option is option 3.  Because, while I was test-driving ORB,
> it crashed several times due to null pointer exception from the Java
> code.  And when it does that, it takes the whole soffice process down
> with it.

	And for those complaining about the idea of removing ORB altogether:
doing some work to help out improve the stability of the implementation
sounds like it would be a good plan. Rather than just wishing it was
better, we need (new) developer resource applying to fixing it, with a
set of clearly filed and isolated bug reports - preferably with the Java
stack-frames that can come from the console (I think), and so on. If the
functionality is extremely sub-standard, and creates the risk of
data-loss for its users, then we may well want to disable it - or make
it 'experimental'. "just reverting a commit" is not an easy thing to do
- it requires first finding the problematic commit, also there are a lot
of interlocking pieces in most such piles of software :-) so again, real
developer resource is required: that can be grown out of sweat & tears
from technical QA guys digging deeper - or preferably from interest from
those who most need / use the feature.

	ATB,

		Michael.

-- 
 michael.meeks at novell.com  <><, Pseudo Engineer, itinerant idiot



More information about the LibreOffice mailing list