incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [PROPOSAL] more clarification on Java -- changes to
Date Tue, 17 Jul 2012 16:13:20 GMT
On Tue, Jul 17, 2012 at 11:55 AM, Kay Schenk <kay.schenk@gmail.com> wrote:
> On Tue, Jul 17, 2012 at 12:26 AM, Larry Gusaas <larry.gusaas@gmail.com>wrote:
>
>> On 2012-07-17 1:15 AM J├╝rgen Schmidt wrote:
>>
>>> I agree in general to you and thanks for summarizing this topic. I have
>>> only one point to add, why should we mention potential problems that we
>>> can't reproduce? In this case I would not mention it, it would be
>>> different if we couldn't fix the problem. But we simply can't reproduce
>>> it.
>>>
>>
>> Check how many times this problem has been reported on the users forum.
>> The collective wisdom of all the people giving support for windows is to
>> use Java 1.6 32 bit. I don't use Windows but I recall that many of the
>> reported problems were on new installations of OpenOffice.
>>
>> --
>> ______________________________**___
>>
>> Larry I. Gusaas
>> Moose Jaw, Saskatchewan Canada
>> Website: http://larry-gusaas.com
>> "An artist is never ahead of his time but most people are far behind
>> theirs." - Edgard Varese
>>
>>
>>
> Juergen --
>
> Hi. I'm going to take Larry's advice on this one. I did see your comments
> in the issues re not able to reproduce. Unfortunately, with these kinds of
> situations -- OS differences, levels of OS patching difference, etc. --
> it's a tough call. What I will say is that there have been SOME issues with
> using 64-bit Oracle Java on 64-bit Windows, the problems are NOT
> consistent, and may, in fact, be due to extension problems with some advice
> on how to troubleshoot. I woudl not make a blanket statement that ALL
> Windows users should only use 32-bit Java.
>
> So, stay tuned. I'll do what I think is reasonable, and hopefully not point
> fingers exclusively at AOO 3.4.
>

IMHO, we should have a stronger sense of what a given release
"supports".  We support what we test.  We should state clearly what we
support.  Our testing scenarios should include clean installs and
upgrade installs.  If they both work in our testing, then that should
be enough to state that they are supported.

Of course, we should try to avoid changes in supported platforms that
break 3rd party extensions.  But we cannot control all the crazy
things that some extensions might do.

It is too late for this release, but in the future we might engage
with the extension authors via a mailing list.  Let them know in
advance that for version 3.x.y we will be supporting JDK version Z.
Make sure they have access to dev snapshot builds and have the
opportunity to test and adapt their extensions as needed and to give
us feedback.

If the first time we hear about an extension incompatibility is from
users, then that is a sign we have a problem with communications with
the extension author, right?  If they are not testing their extensions
at the same time we're testing our dev snapshots, then we have a
problem, right?

-Rob


>
>
> --
> ----------------------------------------------------------------------------------------
> MzK
>
> "I would rather have a donkey that takes me there
>  than a horse that will not fare."
>                                           -- Portuguese proverb

Mime
View raw message