You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2012/03/05 18:29:43 UTC

[EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)

I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.

I also suspect that it is not a good idea to rebrand the Extensions and Templates pages at SourceForge quite so strongly, since the only extensions that are there now are for OO.o (and perhaps LibreOffice).

 - Dennis

-----Original Message-----
From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com] 
Sent: Monday, March 05, 2012 02:06
To: ooo-dev@incubator.apache.org
Subject: Re: Calling all volunteers: It is time to test

On 3/2/12 6:38 PM, Larry Gusaas wrote:
> On 2012-02-29 8:18 AM Rob Weir wrote:
>> Once you have installed, launch OpenOffice and look at the Help/About
>> box. If the revision shown there matches the build you installed
>> (e..g, "r1293550") then the install was a success. Please send a short
>> note to theooo-dev@incubator.apache.org telling us what platform and
>> scenario you installed (fresh install, upgrade, install next to
>> LibreOffice, etc.). This will help us understand what scenarios have
>> already been attempted and which have not.
>
> Using MacBook with OS X version 10.6.8
>
> Downloaded OOo_3.4.0_MacOS_x86_install_en-US.dmg
> Successfully installed replacing installation of OOo 3.3
>
> Installation deleted all of the extensions in my user profile. Quit OOo
> and replaced extension folder in my profile from my backup copy.
> Restarted OOo 3.4 and extensions deleted again. Will try installed
> individual extensions later today.

Hi Larry,

unfortunately extensions get lost because of the dropped Berkeley DB 
which was used to manage installed extensions. We haven't found a simple 
solution to migrate it. This will be documented in the release notes.

Sorry

Juergen


>
> All .odt files I opened worked. Was able to work with and save in
> Writer. The one database I have works. Will do further testing later.
>


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/5/12 6:29 PM, Dennis E. Hamilton wrote:
> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>
> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>
> I also suspect that it is not a good idea to rebrand the Extensions and Templates pages at SourceForge quite so strongly, since the only extensions that are there now are for OO.o (and perhaps LibreOffice).
>

I don't understand this last point. The extension repository is for 
OpenOffice and the extensions should run on Apache OpenOffice as well if 
there is no minimal version dependency. What is exactly your point with 
the rebranding?

Apache OpenOffice = the continuation of OpenOffice.org

Juergen


>   - Dennis
>
> -----Original Message-----
> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
> Sent: Monday, March 05, 2012 02:06
> To: ooo-dev@incubator.apache.org
> Subject: Re: Calling all volunteers: It is time to test
>
> On 3/2/12 6:38 PM, Larry Gusaas wrote:
>> On 2012-02-29 8:18 AM Rob Weir wrote:
>>> Once you have installed, launch OpenOffice and look at the Help/About
>>> box. If the revision shown there matches the build you installed
>>> (e..g, "r1293550") then the install was a success. Please send a short
>>> note to theooo-dev@incubator.apache.org telling us what platform and
>>> scenario you installed (fresh install, upgrade, install next to
>>> LibreOffice, etc.). This will help us understand what scenarios have
>>> already been attempted and which have not.
>>
>> Using MacBook with OS X version 10.6.8
>>
>> Downloaded OOo_3.4.0_MacOS_x86_install_en-US.dmg
>> Successfully installed replacing installation of OOo 3.3
>>
>> Installation deleted all of the extensions in my user profile. Quit OOo
>> and replaced extension folder in my profile from my backup copy.
>> Restarted OOo 3.4 and extensions deleted again. Will try installed
>> individual extensions later today.
>
> Hi Larry,
>
> unfortunately extensions get lost because of the dropped Berkeley DB
> which was used to manage installed extensions. We haven't found a simple
> solution to migrate it. This will be documented in the release notes.
>
> Sorry
>
> Juergen
>
>
>>
>> All .odt files I opened worked. Was able to work with and save in
>> Writer. The one database I have works. Will do further testing later.
>>
>


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by RGB ES <rg...@gmail.com>.
Putting everything together, from a non coder point of view: most dev
builds up to now used their own install path and a different user
profile path (at least on Linux), so the problem is not to do that but
IF AOO 3.4 *need* to do that.

Options:

1- Use same install path and same user profile path than 3.3. PROS:
consistent with OOo 3.x behaviour (with x > 1: as someone commented
before, 3.0 did not override 2.4 user profile). CONS: the inevitable
deletion of user installed extensions could left extension related
menu entries that cannot be deleted, with the very negative point that
downgrading to 3.3 will not fix the problem. This have the potential
to provide a negative image to the project: normal users will not
understand what's going on.

2- Use same install path but different user profile path. PROS: if
user downgrade, everything will be as before. CONS: a downgrade could
be needed to finish that urgent work (yes, there are many users that
upgrade in the middle of an important work...)

3- Use a new install path and a new user profile path. PROS: both
programs running safely side by side, giving the user time to migrate
the work slowly and without problems. CONS: disk space?

I prefer option 3, but have no problem if other solutions are used instead.

Regards
Ricardo

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Jürgen Schmidt <jo...@googlemail.com>.
First of all sorry for the top posting.

The whole thread is very annoying and it would have been much better if 
we had this discussion earlier when we have discussed the replacement in 
December.

We were not happy with the solution but saw no real alternative at this 
time. We had a lot of things to do :-(

But after reading this annoying thread I saw at least one real problem 
that we have to address.

On 3/6/12 9:12 AM, Fernand Vanrie wrote:
> I installed 3.4 on windows
>
> 3.3 is gone, what can been repaired, but: all the extensions and there
> macro's are gone as wel. Problematic is that the Menu-toolbars of the
> deleted extensions are still present and pops up when starting. There is
> no way to delete this extentsion-related-toolbars.
> We only can reinstall the extensions !

That is something that we have overseen or not taken into account.

We investigating in an approach to search for installed extensions 
(*.oxt files only) and reinstall them during the first start.

That will only cover (if possible at all) oxt packages and only user 
installed extension. We can't migrate shared extensions.


Juergen


>
> Greetz
>
> Fernand
>
>
>
>> It is one thing to encourage users to remove their older versions.
>>
>> It is another thing to automatically remove them and, along with that,
>> features that they are relying upon.
>>
>> I don't think the ability of OO.o to replace versions in the same line
>> (i.e., 3.* -- and 3.* did not remove 2.* and 1.* as far as I know) is
>> the proper precedent. I think how LibreOffice endeavored not to do
>> that with their first and subsequent releases is the proper precedent.
>> This is not about wearing the crown, it is about serving the user
>> community.
>>
>> - Dennis
>>
>> -----Original Message-----
>> From: Rob Weir [mailto:robweir@apache.org]
>> Sent: Monday, March 05, 2012 10:09
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It
>> is time to test)
>>
>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>> If there is no solution for extensions, Apache OpenOffice 3.4 early
>>> incubator releases should not overload prior versions of OO.o. I
>>> recommend that AOO 3.4 install in its own locations and not do
>>> anything that would prevent side-by-side functioning. (My
>>> recommendation would be that it do that anyhow. But with known
>>> breaking of an important down-level feature, that becomes imperative.)
>>>
>> In general, it is important for OOo 3.3 and earlier installs on
>> desktops to go away. Old releases increasingly become security
>> hazards, especially if they are no longer being actively maintained.
>> We do a great service to the community in general if we overwrite them
>> with the AOO 3.4. This is true even given the inconvenience the user
>> experiences from the need to reinstall extensions.
>>
>> In any case, I think the overwrite is fine. It is what OOo 3.3 and
>> OOo 3.2 did as well by default. We can document in the install
>> intructions how this can be overridden.
>>
>>> I think there should be OOo-dev releases only until this is handled
>>> as well. It is now clear that integration has problems and there is
>>> no reason to provoke more of it.
>>>
>> If you are volunteering to re-write the extension manager client
>> database support, please speak up and let us know your plan.
>>
>>> I also suspect that it is not a good idea to rebrand the Extensions
>>> and Templates pages at SourceForge quite so strongly, since the only
>>> extensions that are there now are for OO.o (and perhaps LibreOffice).
>>>
>>> - Dennis
>>>
>>> -----Original Message-----
>>> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
>>> Sent: Monday, March 05, 2012 02:06
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: Calling all volunteers: It is time to test
>>>
>>> On 3/2/12 6:38 PM, Larry Gusaas wrote:
>>>> On 2012-02-29 8:18 AM Rob Weir wrote:
>>>>> Once you have installed, launch OpenOffice and look at the Help/About
>>>>> box. If the revision shown there matches the build you installed
>>>>> (e..g, "r1293550") then the install was a success. Please send a short
>>>>> note to theooo-dev@incubator.apache.org telling us what platform and
>>>>> scenario you installed (fresh install, upgrade, install next to
>>>>> LibreOffice, etc.). This will help us understand what scenarios have
>>>>> already been attempted and which have not.
>>>> Using MacBook with OS X version 10.6.8
>>>>
>>>> Downloaded OOo_3.4.0_MacOS_x86_install_en-US.dmg
>>>> Successfully installed replacing installation of OOo 3.3
>>>>
>>>> Installation deleted all of the extensions in my user profile. Quit OOo
>>>> and replaced extension folder in my profile from my backup copy.
>>>> Restarted OOo 3.4 and extensions deleted again. Will try installed
>>>> individual extensions later today.
>>> Hi Larry,
>>>
>>> unfortunately extensions get lost because of the dropped Berkeley DB
>>> which was used to manage installed extensions. We haven't found a simple
>>> solution to migrate it. This will be documented in the release notes.
>>>
>>> Sorry
>>>
>>> Juergen
>>>
>>>
>>>> All .odt files I opened worked. Was able to work with and save in
>>>> Writer. The one database I have works. Will do further testing later.
>>>>
>


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Fernand Vanrie <so...@pmgroup.be>.
I installed 3.4 on windows

3.3 is gone, what can been repaired, but:  all the extensions and there 
macro's are gone as wel. Problematic is that the Menu-toolbars of the 
deleted extensions are still present and pops up when starting. There is 
no way to delete this extentsion-related-toolbars.
We only can reinstall the extensions !

Greetz

Fernand



> It is one thing to encourage users to remove their older versions.
>
> It is another thing to automatically remove them and, along with that, features that they are relying upon.
>
> I don't think the ability of OO.o to replace versions in the same line (i.e., 3.* -- and 3.* did not remove 2.* and 1.* as far as I know) is the proper precedent.  I think how LibreOffice endeavored not to do that with their first and subsequent releases is the proper precedent.  This is not about wearing the crown, it is about serving the user community.
>
>   - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, March 05, 2012 10:09
> To: ooo-dev@incubator.apache.org
> Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)
>
> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
> <de...@acm.org>  wrote:
>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>
> In general, it is important for OOo 3.3 and earlier installs on
> desktops to go away. Old releases increasingly become security
> hazards, especially if they are no longer being actively maintained.
> We do a great service to the community in general if we overwrite them
> with the AOO 3.4.  This is true even given the inconvenience the user
> experiences from the need to reinstall extensions.
>
> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
> OOo 3.2 did as well by default.  We can document in the install
> intructions how this can be overridden.
>
>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>>
> If you are volunteering to re-write the extension manager client
> database support, please speak up and let us know your plan.
>
>> I also suspect that it is not a good idea to rebrand the Extensions and Templates pages at SourceForge quite so strongly, since the only extensions that are there now are for OO.o (and perhaps LibreOffice).
>>
>>   - Dennis
>>
>> -----Original Message-----
>> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
>> Sent: Monday, March 05, 2012 02:06
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Calling all volunteers: It is time to test
>>
>> On 3/2/12 6:38 PM, Larry Gusaas wrote:
>>> On 2012-02-29 8:18 AM Rob Weir wrote:
>>>> Once you have installed, launch OpenOffice and look at the Help/About
>>>> box. If the revision shown there matches the build you installed
>>>> (e..g, "r1293550") then the install was a success. Please send a short
>>>> note to theooo-dev@incubator.apache.org telling us what platform and
>>>> scenario you installed (fresh install, upgrade, install next to
>>>> LibreOffice, etc.). This will help us understand what scenarios have
>>>> already been attempted and which have not.
>>> Using MacBook with OS X version 10.6.8
>>>
>>> Downloaded OOo_3.4.0_MacOS_x86_install_en-US.dmg
>>> Successfully installed replacing installation of OOo 3.3
>>>
>>> Installation deleted all of the extensions in my user profile. Quit OOo
>>> and replaced extension folder in my profile from my backup copy.
>>> Restarted OOo 3.4 and extensions deleted again. Will try installed
>>> individual extensions later today.
>> Hi Larry,
>>
>> unfortunately extensions get lost because of the dropped Berkeley DB
>> which was used to manage installed extensions. We haven't found a simple
>> solution to migrate it. This will be documented in the release notes.
>>
>> Sorry
>>
>> Juergen
>>
>>
>>> All .odt files I opened worked. Was able to work with and save in
>>> Writer. The one database I have works. Will do further testing later.
>>>


Re: [CODE] Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by eric b <er...@free.fr>.
OOops, my mail should have started with "hello,"

Apologies, I was not very polite :-/

-- 
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news






[CODE] Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by eric b <er...@free.fr>.
Le 5 mars 12 à 21:29, Rob Weir a écrit :

> On Mon, Mar 5, 2012 at 3:19 PM, Larry Gusaas  
> <la...@gmail.com> wrote:
>> On 2012-03-05 1:44 PM  Rob Weir wrote:
>>>
>>> Again, your opinion carries as far as your willingness to code an
>>> alternative install approach.
>>
>>
>> Are you saying that unless one is willing to provide code there is  
>> no point
>> in making suggestions? I am getting sick of this insulting  
>> attitude that is
>> way too prevalent in open source communities.
>>
>
> I didn't say no point.  But repeating the same suggestion over and
> over and over and over again, with no code is rather pointless.
>
>> Do you want suggestions from anyone other than developers? If so,  
>> change
>> your attitude.
>>
>
> Personally, I want bug reports more than suggestions right now.  But
> code that fixes bugs is golden.


Well, install Apache OpenOffice without use / share / destroy old  
OpenOffice.org preferences is really easy. More precisely, you have  
several place where you'll have to change something :

- scp2/source/ooo/common_brand.scp : contains the "UserInstallation"  
key, where the OpenOffice.org - for us the new Apache OpenOffice -  
user preferences will be put during bootstrap (at first launch).

ProfileItem gid_Brand_Profileitem_Bootstrap_Userinstall
     ProfileID = gid_Brand_Profile_Bootstrap_Ini;
     ModuleID = gid_Module_Root_Brand;
     Section = "Bootstrap";
     Order = 3;
     Key = "UserInstallation";
   #ifdef WNT
     Value = "$SYSUSERCONFIG/%ONEWORDPRODUCTNAME/% 
USERDIRPRODUCTVERSION";
   #elif defined MACOSX
     Value = "$SYSUSERCONFIG/%ONEWORDPRODUCTNAME/% 
USERDIRPRODUCTVERSION";
   #else
     Value = "$SYSUSERCONFIG/.%LCONEWORDPRODUCTNAME/% 
USERDIRPRODUCTVERSION";
   #endif
End


- instsetoo_native/util/openoffice.lst : where the keys are defined,  
depending you build product, or devel or something else. e.g. you can  
define the version number for the preferences, e.g like macros like  
SYSUSERCONFIG , ONEWORDPRODUCTNAME and USERDIRPRODUCTVERSION

As example, in OOo4Kids, USERDIRPRODUCTVERSION contains 1.0, means  
OOo4Kids 1.0, 1.1 ... and the next 1.3 will share the same  
preferences (in ~/... /OOo4Kids/1.0/. In the case I change something  
who will break the preferences, set USERDIRPRODUCTVERSION to 2.0 is  
the safest way to avoid breaking the old prefs, and keep the old  
version working

This will work the same way with OpenOffice.org. Other solution could  
be to replace ONEWORDAPACHEPRODUCTNAME and to use OpenOffice instead,  
or Apache OpenOffice ... whatever different will work imho.

For the curious, another place who worth a try is solenv/bin/modules/ 
installer/scriptitems.pm (grep for SYSUSERCONFIG). Last,  
SYSUSERCONFIG  is builtin in sal/rtl/source/bootstrap.cxx

Of course, I can't decide alone, and I need opinions, and any  
candidate for this easy hack is welcome  :-)


HTH,
Eric

-- 
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news






Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 8:42 PM, Dave Fisher <da...@comcast.net> wrote:
> I think AOO has a problem. I think that a bad upgrade experience is a problem. I think that poor and uncivil treatment of members of the community is also a problem.
>
> On Mar 5, 2012, at 5:11 PM, Rob Weir wrote:
>
>> On Mon, Mar 5, 2012 at 7:39 PM, Dave Fisher <da...@comcast.net> wrote:
>>>
>>> On Mar 5, 2012, at 2:38 PM, Rob Weir wrote:
>>>
>>>> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
>>>>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>>>>>
>>>>>> I'll put it to you quickly simple.  If you have been paying attention
>>>>>> you will realize that we're discussing release blocking issues.
>>>>>
>>>>>
>>>>> I have been paying attention. Have you?
>>>>> In the thread "Calling all volunteers: It is time to test" you wrote
>>>>>
>>>>>   "We could use help verifying the install in all real-world scenarios, on
>>>>> clean OS installs,
>>>>>   as upgrades to previous versions of OOo."  and
>>>>>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
>>>>> what platform and
>>>>>
>>>>>   scenario you installed (fresh install, upgrade, install next to
>>>>> LibreOffice, etc.)."
>>>>>
>>>>> I did an install over OOo on my Mac and reported that it deleted the
>>>>> extensions in my user profile.
>>>>>
>>>>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>>>>> volunteers: It is time to test)" to discuss if  releases of AOO should
>>>>> overwrite the OOo version, thus deleting all installed extensions.
>>>>>
>>>>> Does this not require discussion?
>>>>>
>>>>
>>>> This has been known for several months and has been part of the 3.4
>>>> plan.  We discussed it extensively in early December.  Certainly if
>>>> you have new information, new workarounds, new proposals, or even new
>>>> code, then I'm new we all would love to know about it.  But if you are
>>>> just noticing this for the first time, you might want to check the
>>>> list archives to catch up on the previous discussion first.  Search
>>>> for "berkeleydb".
>>>>
>>>> In any case your questions suggests a simple misunderstanding.  The
>>>> issue with the extensions in 3.4 is not that the 3.4 install is
>>>> overwriting a profile or anything like that.  It is not, as you say.
>>>> that we are "deleting all installed extensions".  The issue is that
>>>> the extensions info in OOo 3.3 was stored locally in Berkeley Db
>>>> database file.  We had to remove berkeleydb because of its
>>>> incompatible license.  So the database file is there, but, even after
>>>> an upgrade, but we're not able to read it.  That is why the extensions
>>>> need to be reinstalled.
>>>
>>> Rob, I think you are the one who has a "simple" misunderstanding. This issue is being re-raised now. Are we sure that there is no way that Berkeley DB can be used?
>>>
>>
>> Actually, there are grve misunderstandings here, both procedural and
>> technical.,  Some have taken the fact that the extensions need to be
>> reinstalled and extrapolated that as evidence that the profiles are
>> overwritten.
>>
>> The procedural error is to think that raising or "re-raising" an issue
>> magically makes code happen.
>>
>>> Subversion seems to allow it - http://subversion.apache.org/faq.html#divining-bdb-version
>>>
>>> Even if it can't be used should it be possible to hack the file to get the strings? The data can't be too difficult to understand.
>>>
>>
>> Patches are welcome.
>>
>>> While not a functional blocker I firmly believe that this is a significant problem for AOO and this should be addressed constructively.
>>>
>>
>> Patches are welcome.
>>
>>> Please don't give me a "where is the code" response.
>>>
>>
>> Patches are welcome.
>
> I explicitly asked that you not give a "where's the code" repsonse, but you are uncivil enough to instead use the passive aggressive "patches are welcome" 3x.
>

Dave, not be honest with me.  If I demanded that you not bug me,
complain about something, not mention something I did, or in general
tried dictate what you can or cannot say, would you do it?  If so,
then please stop complaining about me.  If not, then why would you
expect I am going to listen to you as you try to dictate what I say or
don't say?

-Rob

> If you cannot be constructive then please - you don't have to respond. Please stop damaging our good work with these type of threads.
>
> Best REgards,
> Dave
>
>
>
>>
>> -Rob
>>
>>> Best Regards,
>>> Dave
>>>
>>>
>>>>
>>>>>
>>>>>> Those
>>>>>> are the only changes we're making right now.  Release blocking issues
>>>>>> are issues in BZ that have the 3.4 release blocking issue flag set.
>>>>>> You are welcome to add such an issue if you think one is lacking.  You
>>>>>> can suggest things until you turn blue in the face and it will not
>>>>>> accomplish as much as the simple act of entering an issue once in BZ.
>>>>>
>>>>>
>>>>> Is this not an issue for discussion? Having AOO overwrite, or not overwrite,
>>>>> OOo is a policy decision that needs discussion. Or, as the grand poobah, are
>>>>> you saying it doesn't? Where has this decision been made?
>>>>>
>>>>
>>>> This was decided last December when we discussed how to deal with the
>>>> removal of berkeleydb.  I think we're all open to better ideas and
>>>> better proposals if you have them.  But please also have some respect
>>>> for those who looked into this issue in detail previously.
>>>>
>>>>>
>>>>>> But I remind you that the fact that extensions will need to be
>>>>>> reinstalled in 3.4 is something that has been well-known in this
>>>>>> project for nearly 6 months now.  But no one has cared to do anything
>>>>>> about it.  And no one has raised it as release blocking issue, not
>>>>>> even as of today.
>>>>>
>>>>>
>>>>> And now the decision has to be made about how to deal with the problem.
>>>>> Overwriting OOo and eliminating the extensions will create a huge howl from
>>>>> tons of users and create unnecessary extra work for the people providing
>>>>> user support.
>>>>>
>>>>
>>>> Again, I recommend you learn the facts, read the list archives, and
>>>> then if at that time you have additional insights, I'm sure we'd all
>>>> love to hear them.
>>>>
>>>> Regards,
>>>>
>>>> -Rob
>>>>
>>>>>
>>>>> --
>>>>> _________________________________
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Dave Fisher <da...@comcast.net>.
I think AOO has a problem. I think that a bad upgrade experience is a problem. I think that poor and uncivil treatment of members of the community is also a problem.

On Mar 5, 2012, at 5:11 PM, Rob Weir wrote:

> On Mon, Mar 5, 2012 at 7:39 PM, Dave Fisher <da...@comcast.net> wrote:
>> 
>> On Mar 5, 2012, at 2:38 PM, Rob Weir wrote:
>> 
>>> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
>>>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>>>> 
>>>>> I'll put it to you quickly simple.  If you have been paying attention
>>>>> you will realize that we're discussing release blocking issues.
>>>> 
>>>> 
>>>> I have been paying attention. Have you?
>>>> In the thread "Calling all volunteers: It is time to test" you wrote
>>>> 
>>>>   "We could use help verifying the install in all real-world scenarios, on
>>>> clean OS installs,
>>>>   as upgrades to previous versions of OOo."  and
>>>>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
>>>> what platform and
>>>> 
>>>>   scenario you installed (fresh install, upgrade, install next to
>>>> LibreOffice, etc.)."
>>>> 
>>>> I did an install over OOo on my Mac and reported that it deleted the
>>>> extensions in my user profile.
>>>> 
>>>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>>>> volunteers: It is time to test)" to discuss if  releases of AOO should
>>>> overwrite the OOo version, thus deleting all installed extensions.
>>>> 
>>>> Does this not require discussion?
>>>> 
>>> 
>>> This has been known for several months and has been part of the 3.4
>>> plan.  We discussed it extensively in early December.  Certainly if
>>> you have new information, new workarounds, new proposals, or even new
>>> code, then I'm new we all would love to know about it.  But if you are
>>> just noticing this for the first time, you might want to check the
>>> list archives to catch up on the previous discussion first.  Search
>>> for "berkeleydb".
>>> 
>>> In any case your questions suggests a simple misunderstanding.  The
>>> issue with the extensions in 3.4 is not that the 3.4 install is
>>> overwriting a profile or anything like that.  It is not, as you say.
>>> that we are "deleting all installed extensions".  The issue is that
>>> the extensions info in OOo 3.3 was stored locally in Berkeley Db
>>> database file.  We had to remove berkeleydb because of its
>>> incompatible license.  So the database file is there, but, even after
>>> an upgrade, but we're not able to read it.  That is why the extensions
>>> need to be reinstalled.
>> 
>> Rob, I think you are the one who has a "simple" misunderstanding. This issue is being re-raised now. Are we sure that there is no way that Berkeley DB can be used?
>> 
> 
> Actually, there are grve misunderstandings here, both procedural and
> technical.,  Some have taken the fact that the extensions need to be
> reinstalled and extrapolated that as evidence that the profiles are
> overwritten.
> 
> The procedural error is to think that raising or "re-raising" an issue
> magically makes code happen.
> 
>> Subversion seems to allow it - http://subversion.apache.org/faq.html#divining-bdb-version
>> 
>> Even if it can't be used should it be possible to hack the file to get the strings? The data can't be too difficult to understand.
>> 
> 
> Patches are welcome.
> 
>> While not a functional blocker I firmly believe that this is a significant problem for AOO and this should be addressed constructively.
>> 
> 
> Patches are welcome.
> 
>> Please don't give me a "where is the code" response.
>> 
> 
> Patches are welcome.

I explicitly asked that you not give a "where's the code" repsonse, but you are uncivil enough to instead use the passive aggressive "patches are welcome" 3x.

If you cannot be constructive then please - you don't have to respond. Please stop damaging our good work with these type of threads.

Best REgards,
Dave



> 
> -Rob
> 
>> Best Regards,
>> Dave
>> 
>> 
>>> 
>>>> 
>>>>> Those
>>>>> are the only changes we're making right now.  Release blocking issues
>>>>> are issues in BZ that have the 3.4 release blocking issue flag set.
>>>>> You are welcome to add such an issue if you think one is lacking.  You
>>>>> can suggest things until you turn blue in the face and it will not
>>>>> accomplish as much as the simple act of entering an issue once in BZ.
>>>> 
>>>> 
>>>> Is this not an issue for discussion? Having AOO overwrite, or not overwrite,
>>>> OOo is a policy decision that needs discussion. Or, as the grand poobah, are
>>>> you saying it doesn't? Where has this decision been made?
>>>> 
>>> 
>>> This was decided last December when we discussed how to deal with the
>>> removal of berkeleydb.  I think we're all open to better ideas and
>>> better proposals if you have them.  But please also have some respect
>>> for those who looked into this issue in detail previously.
>>> 
>>>> 
>>>>> But I remind you that the fact that extensions will need to be
>>>>> reinstalled in 3.4 is something that has been well-known in this
>>>>> project for nearly 6 months now.  But no one has cared to do anything
>>>>> about it.  And no one has raised it as release blocking issue, not
>>>>> even as of today.
>>>> 
>>>> 
>>>> And now the decision has to be made about how to deal with the problem.
>>>> Overwriting OOo and eliminating the extensions will create a huge howl from
>>>> tons of users and create unnecessary extra work for the people providing
>>>> user support.
>>>> 
>>> 
>>> Again, I recommend you learn the facts, read the list archives, and
>>> then if at that time you have additional insights, I'm sure we'd all
>>> love to hear them.
>>> 
>>> Regards,
>>> 
>>> -Rob
>>> 
>>>> 
>>>> --
>>>> _________________________________
>>>> 
>>>> 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
>>>> 
>>>> 
>> 


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Joe Schaefer <jo...@yahoo.com>.
Could the two of you get a room or something?
Most of us are just waiting for this stupid
conversation to end, but if you haven't figured
that out yet please take this off-list.

THX




>________________________________
> From: Larry Gusaas <la...@gmail.com>
>To: ooo-dev@incubator.apache.org 
>Sent: Monday, March 5, 2012 9:18 PM
>Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)
> 
>
>On 2012-03-05 7:51 PM  Rob Weir wrote:
>> On Mon, Mar 5, 2012 at 8:45 PM, Larry Gusaas<la...@gmail.com>  wrote:
>> 
>>> I have never said that profiles are overwritten. I said that the extensions
>>> were deleted from the user profile. Please read what has been written before
>>> accusing people of "grave misunderstandings".
>> And I never said that you did.  But others have.  That's why I suggest
>> we get an issue into BZ ASAP so it is clear to all what exactly we're
>> talking about.
>
>Which others have said that? I just looked through the thread and did not see anyone saying the user profile was overwritten.
>
>The issue seems clear to everyone else commenting on it.
>
>-- _________________________________
>
>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
>
>
>
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 7:51 PM  Rob Weir wrote:
> On Mon, Mar 5, 2012 at 8:45 PM, Larry Gusaas<la...@gmail.com>  wrote:
>
>> I have never said that profiles are overwritten. I said that the extensions
>> were deleted from the user profile. Please read what has been written before
>> accusing people of "grave misunderstandings".
> And I never said that you did.  But others have.  That's why I suggest
> we get an issue into BZ ASAP so it is clear to all what exactly we're
> talking about.

Which others have said that? I just looked through the thread and did not see anyone saying the 
user profile was overwritten.

The issue seems clear to everyone else commenting on it.

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 8:45 PM, Larry Gusaas <la...@gmail.com> wrote:
> On 2012-03-05 7:11 PM  Rob Weir wrote:
>>
>> Actually, there are grve misunderstandings here, both procedural and
>> technical.,  Some have taken the fact that the extensions need to be
>> reinstalled and extrapolated that as evidence that the profiles are
>> overwritten.
>
>
> I have never said that profiles are overwritten. I said that the extensions
> were deleted from the user profile. Please read what has been written before
> accusing people of "grave misunderstandings".
>

And I never said that you did.  But others have.  That's why I suggest
we get an issue into BZ ASAP so it is clear to all what exactly we're
talking about.

-Rob

>
> --
> _________________________________
>
> 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
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 7:11 PM  Rob Weir wrote:
> Actually, there are grve misunderstandings here, both procedural and
> technical.,  Some have taken the fact that the extensions need to be
> reinstalled and extrapolated that as evidence that the profiles are
> overwritten.

I have never said that profiles are overwritten. I said that the extensions were deleted from 
the user profile. Please read what has been written before accusing people of "grave 
misunderstandings".

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 7:39 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Mar 5, 2012, at 2:38 PM, Rob Weir wrote:
>
>> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
>>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>>>
>>>> I'll put it to you quickly simple.  If you have been paying attention
>>>> you will realize that we're discussing release blocking issues.
>>>
>>>
>>> I have been paying attention. Have you?
>>> In the thread "Calling all volunteers: It is time to test" you wrote
>>>
>>>   "We could use help verifying the install in all real-world scenarios, on
>>> clean OS installs,
>>>   as upgrades to previous versions of OOo."  and
>>>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
>>> what platform and
>>>
>>>   scenario you installed (fresh install, upgrade, install next to
>>> LibreOffice, etc.)."
>>>
>>> I did an install over OOo on my Mac and reported that it deleted the
>>> extensions in my user profile.
>>>
>>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>>> volunteers: It is time to test)" to discuss if  releases of AOO should
>>> overwrite the OOo version, thus deleting all installed extensions.
>>>
>>> Does this not require discussion?
>>>
>>
>> This has been known for several months and has been part of the 3.4
>> plan.  We discussed it extensively in early December.  Certainly if
>> you have new information, new workarounds, new proposals, or even new
>> code, then I'm new we all would love to know about it.  But if you are
>> just noticing this for the first time, you might want to check the
>> list archives to catch up on the previous discussion first.  Search
>> for "berkeleydb".
>>
>> In any case your questions suggests a simple misunderstanding.  The
>> issue with the extensions in 3.4 is not that the 3.4 install is
>> overwriting a profile or anything like that.  It is not, as you say.
>> that we are "deleting all installed extensions".  The issue is that
>> the extensions info in OOo 3.3 was stored locally in Berkeley Db
>> database file.  We had to remove berkeleydb because of its
>> incompatible license.  So the database file is there, but, even after
>> an upgrade, but we're not able to read it.  That is why the extensions
>> need to be reinstalled.
>
> Rob, I think you are the one who has a "simple" misunderstanding. This issue is being re-raised now. Are we sure that there is no way that Berkeley DB can be used?
>

Actually, there are grve misunderstandings here, both procedural and
technical.,  Some have taken the fact that the extensions need to be
reinstalled and extrapolated that as evidence that the profiles are
overwritten.

The procedural error is to think that raising or "re-raising" an issue
magically makes code happen.

> Subversion seems to allow it - http://subversion.apache.org/faq.html#divining-bdb-version
>
> Even if it can't be used should it be possible to hack the file to get the strings? The data can't be too difficult to understand.
>

Patches are welcome.

> While not a functional blocker I firmly believe that this is a significant problem for AOO and this should be addressed constructively.
>

Patches are welcome.

> Please don't give me a "where is the code" response.
>

Patches are welcome.

-Rob

> Best Regards,
> Dave
>
>
>>
>>>
>>>> Those
>>>> are the only changes we're making right now.  Release blocking issues
>>>> are issues in BZ that have the 3.4 release blocking issue flag set.
>>>> You are welcome to add such an issue if you think one is lacking.  You
>>>> can suggest things until you turn blue in the face and it will not
>>>> accomplish as much as the simple act of entering an issue once in BZ.
>>>
>>>
>>> Is this not an issue for discussion? Having AOO overwrite, or not overwrite,
>>> OOo is a policy decision that needs discussion. Or, as the grand poobah, are
>>> you saying it doesn't? Where has this decision been made?
>>>
>>
>> This was decided last December when we discussed how to deal with the
>> removal of berkeleydb.  I think we're all open to better ideas and
>> better proposals if you have them.  But please also have some respect
>> for those who looked into this issue in detail previously.
>>
>>>
>>>> But I remind you that the fact that extensions will need to be
>>>> reinstalled in 3.4 is something that has been well-known in this
>>>> project for nearly 6 months now.  But no one has cared to do anything
>>>> about it.  And no one has raised it as release blocking issue, not
>>>> even as of today.
>>>
>>>
>>> And now the decision has to be made about how to deal with the problem.
>>> Overwriting OOo and eliminating the extensions will create a huge howl from
>>> tons of users and create unnecessary extra work for the people providing
>>> user support.
>>>
>>
>> Again, I recommend you learn the facts, read the list archives, and
>> then if at that time you have additional insights, I'm sure we'd all
>> love to hear them.
>>
>> Regards,
>>
>> -Rob
>>
>>>
>>> --
>>> _________________________________
>>>
>>> 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
>>>
>>>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Dave Fisher <da...@comcast.net>.
On Mar 5, 2012, at 2:38 PM, Rob Weir wrote:

> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>> 
>>> I'll put it to you quickly simple.  If you have been paying attention
>>> you will realize that we're discussing release blocking issues.
>> 
>> 
>> I have been paying attention. Have you?
>> In the thread "Calling all volunteers: It is time to test" you wrote
>> 
>>   "We could use help verifying the install in all real-world scenarios, on
>> clean OS installs,
>>   as upgrades to previous versions of OOo."  and
>>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
>> what platform and
>> 
>>   scenario you installed (fresh install, upgrade, install next to
>> LibreOffice, etc.)."
>> 
>> I did an install over OOo on my Mac and reported that it deleted the
>> extensions in my user profile.
>> 
>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>> volunteers: It is time to test)" to discuss if  releases of AOO should
>> overwrite the OOo version, thus deleting all installed extensions.
>> 
>> Does this not require discussion?
>> 
> 
> This has been known for several months and has been part of the 3.4
> plan.  We discussed it extensively in early December.  Certainly if
> you have new information, new workarounds, new proposals, or even new
> code, then I'm new we all would love to know about it.  But if you are
> just noticing this for the first time, you might want to check the
> list archives to catch up on the previous discussion first.  Search
> for "berkeleydb".
> 
> In any case your questions suggests a simple misunderstanding.  The
> issue with the extensions in 3.4 is not that the 3.4 install is
> overwriting a profile or anything like that.  It is not, as you say.
> that we are "deleting all installed extensions".  The issue is that
> the extensions info in OOo 3.3 was stored locally in Berkeley Db
> database file.  We had to remove berkeleydb because of its
> incompatible license.  So the database file is there, but, even after
> an upgrade, but we're not able to read it.  That is why the extensions
> need to be reinstalled.

Rob, I think you are the one who has a "simple" misunderstanding. This issue is being re-raised now. Are we sure that there is no way that Berkeley DB can be used?

Subversion seems to allow it - http://subversion.apache.org/faq.html#divining-bdb-version

Even if it can't be used should it be possible to hack the file to get the strings? The data can't be too difficult to understand.

While not a functional blocker I firmly believe that this is a significant problem for AOO and this should be addressed constructively.

Please don't give me a "where is the code" response.

Best Regards,
Dave


> 
>> 
>>> Those
>>> are the only changes we're making right now.  Release blocking issues
>>> are issues in BZ that have the 3.4 release blocking issue flag set.
>>> You are welcome to add such an issue if you think one is lacking.  You
>>> can suggest things until you turn blue in the face and it will not
>>> accomplish as much as the simple act of entering an issue once in BZ.
>> 
>> 
>> Is this not an issue for discussion? Having AOO overwrite, or not overwrite,
>> OOo is a policy decision that needs discussion. Or, as the grand poobah, are
>> you saying it doesn't? Where has this decision been made?
>> 
> 
> This was decided last December when we discussed how to deal with the
> removal of berkeleydb.  I think we're all open to better ideas and
> better proposals if you have them.  But please also have some respect
> for those who looked into this issue in detail previously.
> 
>> 
>>> But I remind you that the fact that extensions will need to be
>>> reinstalled in 3.4 is something that has been well-known in this
>>> project for nearly 6 months now.  But no one has cared to do anything
>>> about it.  And no one has raised it as release blocking issue, not
>>> even as of today.
>> 
>> 
>> And now the decision has to be made about how to deal with the problem.
>> Overwriting OOo and eliminating the extensions will create a huge howl from
>> tons of users and create unnecessary extra work for the people providing
>> user support.
>> 
> 
> Again, I recommend you learn the facts, read the list archives, and
> then if at that time you have additional insights, I'm sure we'd all
> love to hear them.
> 
> Regards,
> 
> -Rob
> 
>> 
>> --
>> _________________________________
>> 
>> 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
>> 
>> 


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 7:55 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I emphasized that my practice is a personal one and I did not presume that it was shared by this project.
>
> On the other hand, I am not so willing to anoint the Apache OpenOffice project as being  "this project for many years, where point releases do overlay prior releases."  Whether that was wise or not, I claim it is unwise of us for releases of Apache OpenOffice.
>
> I'm also amazed that anyone here would justify anything by saying we're no worse than Microsoft, in effect, with the arguably hyperbolic claim that "Microsoft breaks their plugins with every release and requires reinstall."
>

Actually, Dennis, I'm justifying the current behavior based on not
seeing any practical alternative, as well as the fact that no one has
volunteered a fix, even given the fact that this issue has been known
for over 3 months.  That is reality.

The Microsoft example was to demonstrate that this is not an
earth-shattering problem, that users do not die from having to
reinstall extensions, that some users are actually accustomed to this.

Of course, if you or anyone else wants to provide a better solution,
then I have no objection if they want to give it a try.  In the end
we're a do-ocracy.  That's how we prioritize things.  It is done based
on what volunteers volunteer to do, where they put their effort.  It
is not based on the wishes of those who stand on the sidelines and
"suggest".  Maybe for trivial fixes a mere suggestion would receive a
charitable response from a programmer.  But I would not count on that
for more significant efforts.

-Rob



>  - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, March 05, 2012 15:08
> To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
> Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)
>
> On Mon, Mar 5, 2012 at 6:03 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> I recall the discussion about the BerkeleyDB.  However, the dots with respect to the current state and consequences for users were not connected for me until I saw Jürgen Schmidt's reply today concerning the experience of Larry Gusaas.
>>
>> My creation of this derivative thread was immediate.  It was inspired by situation being made so clear.
>>
>> I don't recall these consequences being so evident until the testing of the "system integration" install versions began last week.  As a matter of my *personal* policy, I would never release in a way that automatically removed previous versions, especially for a release under a reconstituted project.  But that's a matter of personal principles.
>>
>
> Your "personal policy" goes against the constant practice of this
> project for many many years, where point releases do overlay prior
> releases.
>
>> I do not have the experience and skills to make such changes to the Apache OpenOffice code base.  I do have the means to detect and demonstrate defects and make Bugzilla reports.  I can also recommend that the advice of RGB ES and Eric b be drawn upon. And I agree with Larry and Jean that this is a significant policy issue.
>>
>
> Please do.  I'd love to see the BZ issues.  This would make the
> question concrete rather than the rampant speculation I've otherwise
> read today.
>
>> Perhaps this issue could have been surfaced and considered before now.  It doesn't matter.  It is clearly before us at this moment.
>>
>>  - Dennis
>>
>>
>>
>> -----Original Message-----
>> From: Rob Weir [mailto:robweir@apache.org]
>> Sent: Monday, March 05, 2012 14:39
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)
>>
>> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
>>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>>>
>>>> I'll put it to you quickly simple.  If you have been paying attention
>>>> you will realize that we're discussing release blocking issues.
>>>
>>>
>>> I have been paying attention. Have you?
>>> In the thread "Calling all volunteers: It is time to test" you wrote
>>>
>>>   "We could use help verifying the install in all real-world scenarios, on
>>> clean OS installs,
>>>   as upgrades to previous versions of OOo."  and
>>>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
>>> what platform and
>>>
>>>   scenario you installed (fresh install, upgrade, install next to
>>> LibreOffice, etc.)."
>>>
>>> I did an install over OOo on my Mac and reported that it deleted the
>>> extensions in my user profile.
>>>
>>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>>> volunteers: It is time to test)" to discuss if  releases of AOO should
>>> overwrite the OOo version, thus deleting all installed extensions.
>>>
>>> Does this not require discussion?
>>>
>>
>> This has been known for several months and has been part of the 3.4
>> plan.  We discussed it extensively in early December.  Certainly if
>> you have new information, new workarounds, new proposals, or even new
>> code, then I'm new we all would love to know about it.  But if you are
>> just noticing this for the first time, you might want to check the
>> list archives to catch up on the previous discussion first.  Search
>> for "berkeleydb".
>>
>> [ ... ]
>>
>

RE: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by "Dennis E. Hamilton" <de...@acm.org>.
I emphasized that my practice is a personal one and I did not presume that it was shared by this project.

On the other hand, I am not so willing to anoint the Apache OpenOffice project as being  "this project for many years, where point releases do overlay prior releases."  Whether that was wise or not, I claim it is unwise of us for releases of Apache OpenOffice.

I'm also amazed that anyone here would justify anything by saying we're no worse than Microsoft, in effect, with the arguably hyperbolic claim that "Microsoft breaks their plugins with every release and requires reinstall."

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Monday, March 05, 2012 15:08
To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

On Mon, Mar 5, 2012 at 6:03 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I recall the discussion about the BerkeleyDB.  However, the dots with respect to the current state and consequences for users were not connected for me until I saw Jürgen Schmidt's reply today concerning the experience of Larry Gusaas.
>
> My creation of this derivative thread was immediate.  It was inspired by situation being made so clear.
>
> I don't recall these consequences being so evident until the testing of the "system integration" install versions began last week.  As a matter of my *personal* policy, I would never release in a way that automatically removed previous versions, especially for a release under a reconstituted project.  But that's a matter of personal principles.
>

Your "personal policy" goes against the constant practice of this
project for many many years, where point releases do overlay prior
releases.

> I do not have the experience and skills to make such changes to the Apache OpenOffice code base.  I do have the means to detect and demonstrate defects and make Bugzilla reports.  I can also recommend that the advice of RGB ES and Eric b be drawn upon. And I agree with Larry and Jean that this is a significant policy issue.
>

Please do.  I'd love to see the BZ issues.  This would make the
question concrete rather than the rampant speculation I've otherwise
read today.

> Perhaps this issue could have been surfaced and considered before now.  It doesn't matter.  It is clearly before us at this moment.
>
>  - Dennis
>
>
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, March 05, 2012 14:39
> To: ooo-dev@incubator.apache.org
> Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)
>
> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>>
>>> I'll put it to you quickly simple.  If you have been paying attention
>>> you will realize that we're discussing release blocking issues.
>>
>>
>> I have been paying attention. Have you?
>> In the thread "Calling all volunteers: It is time to test" you wrote
>>
>>   "We could use help verifying the install in all real-world scenarios, on
>> clean OS installs,
>>   as upgrades to previous versions of OOo."  and
>>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
>> what platform and
>>
>>   scenario you installed (fresh install, upgrade, install next to
>> LibreOffice, etc.)."
>>
>> I did an install over OOo on my Mac and reported that it deleted the
>> extensions in my user profile.
>>
>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>> volunteers: It is time to test)" to discuss if  releases of AOO should
>> overwrite the OOo version, thus deleting all installed extensions.
>>
>> Does this not require discussion?
>>
>
> This has been known for several months and has been part of the 3.4
> plan.  We discussed it extensively in early December.  Certainly if
> you have new information, new workarounds, new proposals, or even new
> code, then I'm new we all would love to know about it.  But if you are
> just noticing this for the first time, you might want to check the
> list archives to catch up on the previous discussion first.  Search
> for "berkeleydb".
>
> [ ... ]
>


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 6:03 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I recall the discussion about the BerkeleyDB.  However, the dots with respect to the current state and consequences for users were not connected for me until I saw Jürgen Schmidt's reply today concerning the experience of Larry Gusaas.
>
> My creation of this derivative thread was immediate.  It was inspired by situation being made so clear.
>
> I don't recall these consequences being so evident until the testing of the "system integration" install versions began last week.  As a matter of my *personal* policy, I would never release in a way that automatically removed previous versions, especially for a release under a reconstituted project.  But that's a matter of personal principles.
>

Your "personal policy" goes against the constant practice of this
project for many many years, where point releases do overlay prior
releases.

> I do not have the experience and skills to make such changes to the Apache OpenOffice code base.  I do have the means to detect and demonstrate defects and make Bugzilla reports.  I can also recommend that the advice of RGB ES and Eric b be drawn upon. And I agree with Larry and Jean that this is a significant policy issue.
>

Please do.  I'd love to see the BZ issues.  This would make the
question concrete rather than the rampant speculation I've otherwise
read today.

> Perhaps this issue could have been surfaced and considered before now.  It doesn't matter.  It is clearly before us at this moment.
>
>  - Dennis
>
>
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, March 05, 2012 14:39
> To: ooo-dev@incubator.apache.org
> Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)
>
> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>>
>>> I'll put it to you quickly simple.  If you have been paying attention
>>> you will realize that we're discussing release blocking issues.
>>
>>
>> I have been paying attention. Have you?
>> In the thread "Calling all volunteers: It is time to test" you wrote
>>
>>   "We could use help verifying the install in all real-world scenarios, on
>> clean OS installs,
>>   as upgrades to previous versions of OOo."  and
>>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
>> what platform and
>>
>>   scenario you installed (fresh install, upgrade, install next to
>> LibreOffice, etc.)."
>>
>> I did an install over OOo on my Mac and reported that it deleted the
>> extensions in my user profile.
>>
>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>> volunteers: It is time to test)" to discuss if  releases of AOO should
>> overwrite the OOo version, thus deleting all installed extensions.
>>
>> Does this not require discussion?
>>
>
> This has been known for several months and has been part of the 3.4
> plan.  We discussed it extensively in early December.  Certainly if
> you have new information, new workarounds, new proposals, or even new
> code, then I'm new we all would love to know about it.  But if you are
> just noticing this for the first time, you might want to check the
> list archives to catch up on the previous discussion first.  Search
> for "berkeleydb".
>
> [ ... ]
>

RE: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by "Dennis E. Hamilton" <de...@acm.org>.
I recall the discussion about the BerkeleyDB.  However, the dots with respect to the current state and consequences for users were not connected for me until I saw Jürgen Schmidt's reply today concerning the experience of Larry Gusaas.

My creation of this derivative thread was immediate.  It was inspired by situation being made so clear.  

I don't recall these consequences being so evident until the testing of the "system integration" install versions began last week.  As a matter of my *personal* policy, I would never release in a way that automatically removed previous versions, especially for a release under a reconstituted project.  But that's a matter of personal principles.

I do not have the experience and skills to make such changes to the Apache OpenOffice code base.  I do have the means to detect and demonstrate defects and make Bugzilla reports.  I can also recommend that the advice of RGB ES and Eric b be drawn upon. And I agree with Larry and Jean that this is a significant policy issue.  

Perhaps this issue could have been surfaced and considered before now.  It doesn't matter.  It is clearly before us at this moment.

 - Dennis



-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Monday, March 05, 2012 14:39
To: ooo-dev@incubator.apache.org
Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>
>> I'll put it to you quickly simple.  If you have been paying attention
>> you will realize that we're discussing release blocking issues.
>
>
> I have been paying attention. Have you?
> In the thread "Calling all volunteers: It is time to test" you wrote
>
>   "We could use help verifying the install in all real-world scenarios, on
> clean OS installs,
>   as upgrades to previous versions of OOo."  and
>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
> what platform and
>
>   scenario you installed (fresh install, upgrade, install next to
> LibreOffice, etc.)."
>
> I did an install over OOo on my Mac and reported that it deleted the
> extensions in my user profile.
>
> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
> volunteers: It is time to test)" to discuss if  releases of AOO should
> overwrite the OOo version, thus deleting all installed extensions.
>
> Does this not require discussion?
>

This has been known for several months and has been part of the 3.4
plan.  We discussed it extensively in early December.  Certainly if
you have new information, new workarounds, new proposals, or even new
code, then I'm new we all would love to know about it.  But if you are
just noticing this for the first time, you might want to check the
list archives to catch up on the previous discussion first.  Search
for "berkeleydb".

[ ... ]


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Wed, Mar 7, 2012 at 5:07 PM, Keith N. McKenna
<ke...@comcast.net> wrote:

<snip>

>>
>> In any case your questions suggests a simple misunderstanding.  The
>> issue with the extensions in 3.4 is not that the 3.4 install is
>> overwriting a profile or anything like that.  It is not, as you say.
>> that we are "deleting all installed extensions".  The issue is that
>> the extensions info in OOo 3.3 was stored locally in Berkeley Db
>> database file.  We had to remove berkeleydb because of its
>> incompatible license.  So the database file is there, but, even after
>> an upgrade, but we're not able to read it.  That is why the extensions
>> need to be reinstalled.
>>
>        If that is the case it would have behooved you to report that fact
> when you added your "Call for testers" to the Users list. Many people that
> read that list do not subscribe to the Devs' list at all and would not have
> been privy to those discussions around incompatibility of licenses and the
> need to re-install all extensions including dictionaries. I know that it
> surprised me as I only recently subscribed to this list and had no idea they
> had happened.
>

My original note started off saying this:

"First, if you have never tested a pre-release product before, know
that bugs are expected. That is the purpose of testing, to find bugs
so they can be fixed. Bugs could range from UI glitches, to incorrect
formatting to crashes or even data corruption.  So you probably don't
want to use a test build for mission-critical tasks. Of course, I
assume you have already backed up your important documents.  You do
have backups, right?  Ideally you can do your testing on a separate
machine from your main work machine, so if something goes wrong you
will not interfere with your other work."

In other words, pre-release software has all known bugs, as well as
all unknown bugs.  The former are in the release notes or BZ, the
later are what we're looking for.  I was hoping that warning would
dissuade those from testing who were not able to deal with the
inevitable glitches that occur in early testing.

In any case, if I send another invite to the users list I'll certainly
give more background information, including links to the release notes
and open BZ issues.

Regards,

-Rob

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by "Keith N. McKenna" <ke...@comcast.net>.
On 3/5/2012 5:38 PM, Rob Weir wrote:
> On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas<la...@gmail.com>  wrote:
>> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>>
>>> I'll put it to you quickly simple.  If you have been paying attention
>>> you will realize that we're discussing release blocking issues.
>>
>>
>> I have been paying attention. Have you?
>> In the thread "Calling all volunteers: It is time to test" you wrote
>>
>>    "We could use help verifying the install in all real-world scenarios, on
>> clean OS installs,
>>    as upgrades to previous versions of OOo."  and
>>    "Please send a short note to the ooo-dev@incubator.apache.org telling us
>> what platform and
>>
>>    scenario you installed (fresh install, upgrade, install next to
>> LibreOffice, etc.)."
>>
>> I did an install over OOo on my Mac and reported that it deleted the
>> extensions in my user profile.
>>
>> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
>> volunteers: It is time to test)" to discuss if  releases of AOO should
>> overwrite the OOo version, thus deleting all installed extensions.
>>
>> Does this not require discussion?
>>
>
> This has been known for several months and has been part of the 3.4
> plan.  We discussed it extensively in early December.  Certainly if
> you have new information, new workarounds, new proposals, or even new
> code, then I'm new we all would love to know about it.  But if you are
> just noticing this for the first time, you might want to check the
> list archives to catch up on the previous discussion first.  Search
> for "berkeleydb".

Many, such as myself, were not aware that extensions were stored in a 
Berkley database
>
> In any case your questions suggests a simple misunderstanding.  The
> issue with the extensions in 3.4 is not that the 3.4 install is
> overwriting a profile or anything like that.  It is not, as you say.
> that we are "deleting all installed extensions".  The issue is that
> the extensions info in OOo 3.3 was stored locally in Berkeley Db
> database file.  We had to remove berkeleydb because of its
> incompatible license.  So the database file is there, but, even after
> an upgrade, but we're not able to read it.  That is why the extensions
> need to be reinstalled.
>
	If that is the case it would have behooved you to report that fact when 
you added your "Call for testers" to the Users list. Many people that 
read that list do not subscribe to the Devs' list at all and would not 
have been privy to those discussions around incompatibility of licenses 
and the need to re-install all extensions including dictionaries. I know 
that it surprised me as I only recently subscribed to this list and had 
no idea they had happened.

	Had you added the disclaimer around extensions and the reason for it,I 
believe a significant amount of the resulting acrimonious discussion 
would not have taken place.

>>
>>> Those
>>> are the only changes we're making right now.  Release blocking issues
>>> are issues in BZ that have the 3.4 release blocking issue flag set.
>>> You are welcome to add such an issue if you think one is lacking.  You
>>> can suggest things until you turn blue in the face and it will not
>>> accomplish as much as the simple act of entering an issue once in BZ.
>>
>>
>> Is this not an issue for discussion? Having AOO overwrite, or not overwrite,
>> OOo is a policy decision that needs discussion. Or, as the grand poobah, are
>> you saying it doesn't? Where has this decision been made?
>>
>
> This was decided last December when we discussed how to deal with the
> removal of berkeleydb.  I think we're all open to better ideas and
> better proposals if you have them.  But please also have some respect
> for those who looked into this issue in detail previously.
>
>>
	Again, given that it was decided at that time a statement to that 
effect would have been appreciated by those of us in the user community 
when you asked us to participate in the testing instead of having to 
find out about it when we installed the software. One expects problems 
with beta software, but it is just plain curtsey to give a heads-up to 
known problems so that testers do not waste their time reporting 
problems that are already known.

>>> But I remind you that the fact that extensions will need to be
>>> reinstalled in 3.4 is something that has been well-known in this
>>> project for nearly 6 months now.  But no one has cared to do anything
>>> about it.  And no one has raised it as release blocking issue, not
>>> even as of today.
>>
>>

	Again you insist that everyone in the project community has known about 
the problem with extensions for six months. The fact is that not all 
parts of the community where aware of this. As is being shown by the 
discussion that is going on.

Regards
Keith

>> And now the decision has to be made about how to deal with the problem.
>> Overwriting OOo and eliminating the extensions will create a huge howl from
>> tons of users and create unnecessary extra work for the people providing
>> user support.
>>
>
> Again, I recommend you learn the facts, read the list archives, and
> then if at that time you have additional insights, I'm sure we'd all
> love to hear them.
>

> Regards,
>
> -Rob
>
>>
>> --
>> _________________________________
>>
>> 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
>>
>>
>



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Tsutomu Uchino <ha...@gmail.com>.
2012/3/6 Rob Weir <ro...@apache.org>:
> B: Require the user to reinstall extensions, but preserve the user
> settings, so after the extensions are reinstalled the user has all
> their settings and preferences.

The office removes extension directories which are not registered in the pmap
file during start up. But contents created for extension packages placed
under uno_packages/registry are still there and they are shown, for example
menu integration of the extension packages.
After re-installation of extensions, they are still alive. So they
have to be removed
before re-installing extensions.

I wrote migration script to convert db file to pmap using Berkeley db
package in Python.
But this kind of migration working out of the office have to be done before
the first running of 3.4.

Regards,

#! /bin/env python

import bsddb
from optparse import OptionParser
import os
import os.path
import re
import platform

__doc__ = """There is no file spacification for uno_packages.db
and uno_packages.pmap but you can find its implementation in
 main/desktop/source/deployment/dp_persmap.cxx of the source code. """


def get_items(packages):
    """ Open Berkeley database file and read its content.
	
	# Format of uno_packages.db
	# Berkeley detabase
	# Ignore white spaces in key and value
	# key: 0xFF EXTENSION_ID
	# value: TEMP_NAME 0xFF PACKAGE_NAME 0xFF PACKAGE_MIME_TYPE 0xFF VERSION 0xFF 0
	# The last value is always zero in value because of it is not used anymore.
	"""
    items = {}
    d = bsddb.hashopen(packages + ".db", "r")
    for k, v in d.iteritems():
        items[k] = v
    d.close()
    return items


def write_pmap(packages, items):
    """ Write to pmap file.
	
	# Format of uno_packages.pmap
	# file header: Pmp1
	# Ignore white space in the body.
	# body: key \n value \n
	# file footer: \n
	# The 00 ... 0F are replaced with %0 ... %F and
	# % is replaced with %% in key and value.
	"""
    magic = "Pmp1"

    regexp = re.compile("(\x00|\x01|\x02|\x03|\x04|\x05|\x06|\x07|\x08|\x09|\x0a|\x0b|\x0c|\x0d|\x0e|\x0f|%)")
    def encode(m):
        # 00 ... 0F -> %0 ... %F, % -> %%
        c = m.group(0)
        if c == "%":
            return "%%"
        else:
            n = ord(c)
            if n < 0x09:
                return "%%%s" % chr(0x30 + n)
            else:
                return "%%%s" % chr(0x37 + n)

    lines = []
    for k, v in items.iteritems():
        lines.append(regexp.sub(encode, k))
        lines.append(regexp.sub(encode, v))

    lines.append("\n")

    f = open(packages + ".pmap", "w")
    f.write(magic)
    f.write("\n".join(lines))
    f.flush()
    f.close()


def main():
    """ Tries to convert uno_packages.db to pmap. """
    USER_KEY = "user"
    if os.sep == "/":
        data_dir = os.path.join("~", ".openoffice.org")
    elif platform.system() == "Windows":
        release = platform.release()
        if release == "XP" or release == "2000":
            data_dir = os.path.join("~", "Application Data", "OpenOffice.org")
        else:
            data_dir = os.path.join("~", "AppData", "OpenOffice.org")

    parser = OptionParser()
    parser.add_option("-u", dest=USER_KEY,
        help="Data directory of the office. Default: %s" % data_dir)
    parser.set_default(USER_KEY, data_dir)

    options, args = parser.parse_args()

    packages_dir = os.path.join(
        os.path.expanduser(getattr(options, USER_KEY)),
        "3", "user",
        "uno_packages", "cache")

    # check user directory is exist
    if not os.path.exists(packages_dir):
        print("Error: %s is not found." % packages_dir)
        return
    packages_path = os.path.join(packages_dir, "uno_packages")

    items = get_items(packages_path)
    write_pmap(packages_path, items)


if __name__ == "__main__":
    main()

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 10:24 PM, Larry Gusaas <la...@gmail.com> wrote:
> On 2012-03-05 8:17 PM  Rob Weir wrote:
>>
>> As I said before, the point was that requiring users to reinstall
>> extensions is not unreasonable.   It is certainly better than what you
>> are recommending, that users must reinstall extensions but then they
>> also lose every other setting and preference they had in their profile
>> as well,
>
>
> Actually, since a corrupted profile is the largest cause of problems for
> users of OOo and the cure is a new profile, it would be far safer for a
> major update like AOO 3.4 to use a completely new profile. This approach is
> recommended by many of the people giving support for OOo. (I've never done
> that myself, although I have had to replace a corrupted profile.)
>

Even safer would be to reformat the hard drive and reinstall the OS.
But unless the user is reporting symptoms related to corruptions,
these precautions are unnecessary, and cause more user inconvenience
("alienation" as it has been called elsewhere in this thread) than
necessary.  (And yes, I have professionally supported office app
users).

In any case, no one has suggested we eliminate the option for users
(or admins) to install to a new profile if they wish.  We're not
discussing that.  The only thing we're discussing, is what the default
should be.  Should the default be:

A: Lose all user settings and preferences and also require the user to
reinstall extensions

B: Require the user to reinstall extensions, but preserve the user
settings, so after the extensions are reinstalled the user has all
their settings and preferences.

C. Preserve the extensions as well as the settings

Ideally we'd have C.  That is what we had with OOo 3.3 and 3.2.  But
it does not work now due to the removal of Berkeley DB.  I don't think
anyone (except maybe Dennis, since his concerns are orthogonal to the
extensions question) would have complained if we did C.  But now that
we can't do C, it seems absurd to break the user entirely by picking A
rather than allowing the user to easily recover with B.

I'm not saying there are not uses for A.  I'm glad that option is
there,  But it does not make sense for the default option that we
break users even more than the breakage that most people on the thread
are complaining that they find detrimental to users.

> Since talking to you is pointless, I'll let you have the last word when you
> respond to this post. My points have been made and are clear to any
> reasonable person.
>
>
> --
> _________________________________
>
> 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
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 8:17 PM  Rob Weir wrote:
> As I said before, the point was that requiring users to reinstall
> extensions is not unreasonable.   It is certainly better than what you
> are recommending, that users must reinstall extensions but then they
> also lose every other setting and preference they had in their profile
> as well,

Actually, since a corrupted profile is the largest cause of problems for users of OOo and the 
cure is a new profile, it would be far safer for a major update like AOO 3.4 to use a 
completely new profile. This approach is recommended by many of the people giving support for 
OOo. (I've never done that myself, although I have had to replace a corrupted profile.)

Since talking to you is pointless, I'll let you have the last word when you respond to this 
post. My points have been made and are clear to any reasonable person.

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 8:58 PM, Larry Gusaas <la...@gmail.com> wrote:
>
> On 2012-03-05 7:17 PM  Rob Weir wrote:
>>
>> On Mon, Mar 5, 2012 at 7:44 PM, Larry Gusaas<la...@gmail.com>
>>  wrote:
>>>
>>> On 2012-03-05 4:38 PM  Rob Weir wrote:
>>>>
>>>> This has been known for several months and has been part of the 3.4
>>>> plan.
>>>> We discussed it extensively in early December. Certainly if you have new
>>>> information, new workarounds, new proposals, or even new code, then I'm
>>>> new
>>>> we all would love to know about it. But if you are just noticing this
>>>> for
>>>> the first time, you might want to check the list archives to catch up on
>>>> the
>>>> previous discussion first. Search for "berkeleydb".
>>>
>>> The problem with the database was known. The fact that you were planning
>>> to
>>> release a version that overwrote OOo and erased the extensions in the
>>> user
>>> profile was not clear until you asked for testing. And now you are
>>> complaining about us reporting the problems found.
>>>
>> Maybe not clear to you, but the information was provided in early
>> December when the code change was made.  This was not hidden.  The
>> implications of this were plainly stated, for example on the wiki page
>> that explained the user-facing ramifications of removing the Berkeley
>> DB:
>>
>> "The impact is that extensions installed for older versions of
>> OpenOffice have to be re-installed."
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP_Clearance+Impact
>
>
> Once again you are missing the point.  The issue is overwriting 3.4 on the
> previous OOo installation and using the old user profile, which causes the
> deletion of all extensions from the user profile.
>

As we said back in December, 3.4 users will need to reinstall
extensions.   I am not missing the point.  I am the one who wrote that
in the wiki back in December.

> If the user then decides to return to a earlier version, the user profiled
> is fucked and they have to reinstall all extensions. That would not make for
> a happy user.
>

If a user wants to run both 3.3 and 3.4 then they can do that today.
We can certainly make it clear in the install doc how a user can do
this, if they wish.   But I see no reason why this would or should be
the default installation choice.

> It would be better to release as AOO 3.4 and create a totally new profile
> rather than overwrite the program and mess up the old user profile.
>

Once the user has reinstalled the extensions, in what way is the old
user profile messed up?

Remember, not all users have extensions installed. I doubt the
majority do.  Why would we want all users to lose all settings just
because a fraction of users need to reinstall their extensions, users
who if they did reinstall the extensions would have all of there
settings intact? I don't see your recommendation as optimal for users
who are upgrading to AOO 3.4.

> As for precedent, when Sun released OOo 3.0 it created a new profile and did
> not use the profile from OOo 2.xx, at least on Mac installs.
>
> As for you references to Microsoft updates, that is a bunch of crap. Do you
> really want to use Microsoft as an example? Or is that typical of IBM as
> well?
>

As I said before, the point was that requiring users to reinstall
extensions is not unreasonable.   It is certainly better than what you
are recommending, that users must reinstall extensions but then they
also lose every other setting and preference they had in their profile
as well,

-Rob

>
> --
> _________________________________
>
> 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
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 7:17 PM  Rob Weir wrote:
> On Mon, Mar 5, 2012 at 7:44 PM, Larry Gusaas<la...@gmail.com>  wrote:
>> On 2012-03-05 4:38 PM  Rob Weir wrote:
>>> This has been known for several months and has been part of the 3.4 plan.
>>> We discussed it extensively in early December. Certainly if you have new
>>> information, new workarounds, new proposals, or even new code, then I'm new
>>> we all would love to know about it. But if you are just noticing this for
>>> the first time, you might want to check the list archives to catch up on the
>>> previous discussion first. Search for "berkeleydb".
>> The problem with the database was known. The fact that you were planning to
>> release a version that overwrote OOo and erased the extensions in the user
>> profile was not clear until you asked for testing. And now you are
>> complaining about us reporting the problems found.
>>
> Maybe not clear to you, but the information was provided in early
> December when the code change was made.  This was not hidden.  The
> implications of this were plainly stated, for example on the wiki page
> that explained the user-facing ramifications of removing the Berkeley
> DB:
>
> "The impact is that extensions installed for older versions of
> OpenOffice have to be re-installed."
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/IP_Clearance+Impact

Once again you are missing the point.  The issue is overwriting 3.4 on the previous OOo 
installation and using the old user profile, which causes the deletion of all extensions from 
the user profile.

If the user then decides to return to a earlier version, the user profiled is fucked and they 
have to reinstall all extensions. That would not make for a happy user.

It would be better to release as AOO 3.4 and create a totally new profile rather than overwrite 
the program and mess up the old user profile.

As for precedent, when Sun released OOo 3.0 it created a new profile and did not use the 
profile from OOo 2.xx, at least on Mac installs.

As for you references to Microsoft updates, that is a bunch of crap. Do you really want to use 
Microsoft as an example? Or is that typical of IBM as well?

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 7:44 PM, Larry Gusaas <la...@gmail.com> wrote:
>
> On 2012-03-05 4:38 PM  Rob Weir wrote:
>>
>> This has been known for several months and has been part of the 3.4 plan.
>> We discussed it extensively in early December. Certainly if you have new
>> information, new workarounds, new proposals, or even new code, then I'm new
>> we all would love to know about it. But if you are just noticing this for
>> the first time, you might want to check the list archives to catch up on the
>> previous discussion first. Search for "berkeleydb".
>
>
> The problem with the database was known. The fact that you were planning to
> release a version that overwrote OOo and erased the extensions in the user
> profile was not clear until you asked for testing. And now you are
> complaining about us reporting the problems found.
>

Maybe not clear to you, but the information was provided in early
December when the code change was made.  This was not hidden.  The
implications of this were plainly stated, for example on the wiki page
that explained the user-facing ramifications of removing the Berkeley
DB:

"The impact is that extensions installed for older versions of
OpenOffice have to be re-installed."

https://cwiki.apache.org/confluence/display/OOOUSERS/IP_Clearance+Impact


-Rob

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 4:38 PM  Rob Weir wrote:
> This has been known for several months and has been part of the 3.4 plan. We discussed it 
> extensively in early December. Certainly if you have new information, new workarounds, new 
> proposals, or even new code, then I'm new we all would love to know about it. But if you are 
> just noticing this for the first time, you might want to check the list archives to catch up 
> on the previous discussion first. Search for "berkeleydb".

The problem with the database was known. The fact that you were planning to release a version 
that overwrote OOo and erased the extensions in the user profile was not clear until you asked 
for testing. And now you are complaining about us reporting the problems found.

> In any case your questions suggests a simple misunderstanding. The issue with the extensions 
> in 3.4 is not that the 3.4 install is overwriting a profile or anything like that. 

It is not a misunderstanding. I never said that 3.4 was overwriting my user profile. It is 
deleting all the extensions in my user profile. The folder that contained them is empty.

> It is not, as you say. that we are "deleting all installed extensions". 

Then why is the folder that contained them empty? Installing 3.4 does exactly what I said it does.

> The issue is that the extensions info in OOo 3.3 was stored locally in Berkeley Db database 
> file. We had to remove berkeleydb because of its incompatible license. So the database file 
> is there, but, even after an upgrade, but we're not able to read it. That is why the 
> extensions need to be reinstalled.
>>> Those
>>> are the only changes we're making right now.  Release blocking issues
>>> are issues in BZ that have the 3.4 release blocking issue flag set.
>>> You are welcome to add such an issue if you think one is lacking.  You
>>> can suggest things until you turn blue in the face and it will not
>>> accomplish as much as the simple act of entering an issue once in BZ.
>> Is this not an issue for discussion? Having AOO overwrite, or not overwrite,
>> OOo is a policy decision that needs discussion. Or, as the grand poobah, are
>> you saying it doesn't? Where has this decision been made?
>>
> This was decided last December when we discussed how to deal with the
> removal of berkeleydb.  I think we're all open to better ideas and
> better proposals if you have them.  But please also have some respect
> for those who looked into this issue in detail previously.

It was? Then you better look at changing it, unless you want a bunch of disgruntled users on 
your hands.

You asked for reports on installing as an overwrite and now you are trying to dismiss reports 
of the problems it causes.

>>> But I remind you that the fact that extensions will need to be
>>> reinstalled in 3.4 is something that has been well-known in this
>>> project for nearly 6 months now.  But no one has cared to do anything
>>> about it.  And no one has raised it as release blocking issue, not
>>> even as of today.
>> And now the decision has to be made about how to deal with the problem.
>> Overwriting OOo and eliminating the extensions will create a huge howl from
>> tons of users and create unnecessary extra work for the people providing
>> user support.
>>
> Again, I recommend you learn the facts, read the list archives, and
> then if at that time you have additional insights, I'm sure we'd all
> love to hear them.

And I suggest you learn to be less condescending.

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <la...@gmail.com> wrote:
> On 2012-03-05 3:30 PM  Rob Weir wrote:
>>
>> I'll put it to you quickly simple.  If you have been paying attention
>> you will realize that we're discussing release blocking issues.
>
>
> I have been paying attention. Have you?
> In the thread "Calling all volunteers: It is time to test" you wrote
>
>   "We could use help verifying the install in all real-world scenarios, on
> clean OS installs,
>   as upgrades to previous versions of OOo."  and
>   "Please send a short note to the ooo-dev@incubator.apache.org telling us
> what platform and
>
>   scenario you installed (fresh install, upgrade, install next to
> LibreOffice, etc.)."
>
> I did an install over OOo on my Mac and reported that it deleted the
> extensions in my user profile.
>
> Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all
> volunteers: It is time to test)" to discuss if  releases of AOO should
> overwrite the OOo version, thus deleting all installed extensions.
>
> Does this not require discussion?
>

This has been known for several months and has been part of the 3.4
plan.  We discussed it extensively in early December.  Certainly if
you have new information, new workarounds, new proposals, or even new
code, then I'm new we all would love to know about it.  But if you are
just noticing this for the first time, you might want to check the
list archives to catch up on the previous discussion first.  Search
for "berkeleydb".

In any case your questions suggests a simple misunderstanding.  The
issue with the extensions in 3.4 is not that the 3.4 install is
overwriting a profile or anything like that.  It is not, as you say.
that we are "deleting all installed extensions".  The issue is that
the extensions info in OOo 3.3 was stored locally in Berkeley Db
database file.  We had to remove berkeleydb because of its
incompatible license.  So the database file is there, but, even after
an upgrade, but we're not able to read it.  That is why the extensions
need to be reinstalled.

>
>> Those
>> are the only changes we're making right now.  Release blocking issues
>> are issues in BZ that have the 3.4 release blocking issue flag set.
>> You are welcome to add such an issue if you think one is lacking.  You
>> can suggest things until you turn blue in the face and it will not
>> accomplish as much as the simple act of entering an issue once in BZ.
>
>
> Is this not an issue for discussion? Having AOO overwrite, or not overwrite,
> OOo is a policy decision that needs discussion. Or, as the grand poobah, are
> you saying it doesn't? Where has this decision been made?
>

This was decided last December when we discussed how to deal with the
removal of berkeleydb.  I think we're all open to better ideas and
better proposals if you have them.  But please also have some respect
for those who looked into this issue in detail previously.

>
>> But I remind you that the fact that extensions will need to be
>> reinstalled in 3.4 is something that has been well-known in this
>> project for nearly 6 months now.  But no one has cared to do anything
>> about it.  And no one has raised it as release blocking issue, not
>> even as of today.
>
>
> And now the decision has to be made about how to deal with the problem.
> Overwriting OOo and eliminating the extensions will create a huge howl from
> tons of users and create unnecessary extra work for the people providing
> user support.
>

Again, I recommend you learn the facts, read the list archives, and
then if at that time you have additional insights, I'm sure we'd all
love to hear them.

Regards,

-Rob

>
> --
> _________________________________
>
> 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
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Dave Fisher <da...@comcast.net>.
On Mar 5, 2012, at 2:41 PM, Rob Weir wrote:

> On Mon, Mar 5, 2012 at 5:29 PM, RGB ES <rg...@gmail.com> wrote:
>> 2012/3/5 Larry Gusaas <la...@gmail.com>:
>>> Overwriting OOo and eliminating the extensions will create a huge howl from
>>> tons of users and create unnecessary extra work for the people providing
>>> user support.
>> 
>> +1. I think that adding an "a" on the path of both, install folder and
>> user profile (something like ~/.aopenoffice.org/, or even shorter:
>> ~/.aoo/) will prevent some problems and confusion.
> 
> Again, show me the bug report that has a reproducible case for AOO 3.4
> overwriting OOo 3.3.0 profile data.  I hope you agree that the lack of
> such a bug report makes this whole discussion rather bizarre, like
> maybe we have too many opinionated project members chasing after too
> few facts?

If that is true then maybe you should not be responding to this thread.

Regards,
Dave


> 
> -Rob


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 6:06 PM, RGB ES <rg...@gmail.com> wrote:
> 2012/3/5 Rob Weir <ro...@apache.org>:
>> On Mon, Mar 5, 2012 at 5:29 PM, RGB ES <rg...@gmail.com> wrote:
>>> 2012/3/5 Larry Gusaas <la...@gmail.com>:
>>>> Overwriting OOo and eliminating the extensions will create a huge howl from
>>>> tons of users and create unnecessary extra work for the people providing
>>>> user support.
>>>
>>> +1. I think that adding an "a" on the path of both, install folder and
>>> user profile (something like ~/.aopenoffice.org/, or even shorter:
>>> ~/.aoo/) will prevent some problems and confusion.
>>
>> Again, show me the bug report that has a reproducible case for AOO 3.4
>> overwriting OOo 3.3.0 profile data.  I hope you agree that the lack of
>> such a bug report makes this whole discussion rather bizarre, like
>> maybe we have too many opinionated project members chasing after too
>> few facts?
>>
>> -Rob
>
> My "few facts" comes from almost a decade providing support to
> *normal* users that do not look at blogs, mailing lists, wikis... and
> just install an update when they find it. But that is my personal
> experience, it could be subjective...
>

I'm not saying that requiring a reinstall of extensions is a great
thing.  I'm just saying that no one yet has suggested a technical
alternative, and that complaining alone will be unlikely to change
things.

> BTW, according to WordNet "opinionated" means "narrow minded" which I
> think is a little too much, don't you think? After all, I commented on
> this topic only once...

I would not have used that definition.  Take it as you are providing
opinions on the impact of a bug that no one has managed to actually
report to BZ.  So we have speculation rather than facts.  Let's get
the facts, OK?

-Rob
>
> Regards
> Ricardo

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by RGB ES <rg...@gmail.com>.
2012/3/5 Rob Weir <ro...@apache.org>:
> On Mon, Mar 5, 2012 at 5:29 PM, RGB ES <rg...@gmail.com> wrote:
>> 2012/3/5 Larry Gusaas <la...@gmail.com>:
>>> Overwriting OOo and eliminating the extensions will create a huge howl from
>>> tons of users and create unnecessary extra work for the people providing
>>> user support.
>>
>> +1. I think that adding an "a" on the path of both, install folder and
>> user profile (something like ~/.aopenoffice.org/, or even shorter:
>> ~/.aoo/) will prevent some problems and confusion.
>
> Again, show me the bug report that has a reproducible case for AOO 3.4
> overwriting OOo 3.3.0 profile data.  I hope you agree that the lack of
> such a bug report makes this whole discussion rather bizarre, like
> maybe we have too many opinionated project members chasing after too
> few facts?
>
> -Rob

My "few facts" comes from almost a decade providing support to
*normal* users that do not look at blogs, mailing lists, wikis... and
just install an update when they find it. But that is my personal
experience, it could be subjective...

BTW, according to WordNet "opinionated" means "narrow minded" which I
think is a little too much, don't you think? After all, I commented on
this topic only once...

Regards
Ricardo

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 5:29 PM, RGB ES <rg...@gmail.com> wrote:
> 2012/3/5 Larry Gusaas <la...@gmail.com>:
>> Overwriting OOo and eliminating the extensions will create a huge howl from
>> tons of users and create unnecessary extra work for the people providing
>> user support.
>
> +1. I think that adding an "a" on the path of both, install folder and
> user profile (something like ~/.aopenoffice.org/, or even shorter:
> ~/.aoo/) will prevent some problems and confusion.

Again, show me the bug report that has a reproducible case for AOO 3.4
overwriting OOo 3.3.0 profile data.  I hope you agree that the lack of
such a bug report makes this whole discussion rather bizarre, like
maybe we have too many opinionated project members chasing after too
few facts?

-Rob

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by RGB ES <rg...@gmail.com>.
2012/3/5 Larry Gusaas <la...@gmail.com>:
> Overwriting OOo and eliminating the extensions will create a huge howl from
> tons of users and create unnecessary extra work for the people providing
> user support.

+1. I think that adding an "a" on the path of both, install folder and
user profile (something like ~/.aopenoffice.org/, or even shorter:
~/.aoo/) will prevent some problems and confusion.

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 3:30 PM  Rob Weir wrote:
> I'll put it to you quickly simple.  If you have been paying attention
> you will realize that we're discussing release blocking issues.

I have been paying attention. Have you?
In the thread "Calling all volunteers: It is time to test" you wrote

    "We could use help verifying the install in all real-world scenarios, on clean OS installs,
    as upgrades to previous versions of OOo."  and
    "Please send a short note to the ooo-dev@incubator.apache.org telling us what platform and
    scenario you installed (fresh install, upgrade, install next to LibreOffice, etc.)."

I did an install over OOo on my Mac and reported that it deleted the extensions in my user profile.

Dennis started this thread "[EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time 
to test)" to discuss if  releases of AOO should overwrite the OOo version, thus deleting all 
installed extensions.

Does this not require discussion?

> Those
> are the only changes we're making right now.  Release blocking issues
> are issues in BZ that have the 3.4 release blocking issue flag set.
> You are welcome to add such an issue if you think one is lacking.  You
> can suggest things until you turn blue in the face and it will not
> accomplish as much as the simple act of entering an issue once in BZ.

Is this not an issue for discussion? Having AOO overwrite, or not overwrite, OOo is a policy 
decision that needs discussion. Or, as the grand poobah, are you saying it doesn't? Where has 
this decision been made?

> But I remind you that the fact that extensions will need to be
> reinstalled in 3.4 is something that has been well-known in this
> project for nearly 6 months now.  But no one has cared to do anything
> about it.  And no one has raised it as release blocking issue, not
> even as of today.

And now the decision has to be made about how to deal with the problem. Overwriting OOo and 
eliminating the extensions will create a huge howl from tons of users and create unnecessary 
extra work for the people providing user support.

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 4:25 PM, Larry Gusaas <la...@gmail.com> wrote:
>
> On 2012-03-05 2:29 PM  Rob Weir wrote:
>>
>> On Mon, Mar 5, 2012 at 3:19 PM, Larry Gusaas<la...@gmail.com>
>>  wrote:
>>>
>>> On 2012-03-05 1:44 PM  Rob Weir wrote:
>>>>
>>>> Again, your opinion carries as far as your willingness to code an
>>>> alternative install approach.
>>>
>>> Are you saying that unless one is willing to provide code there is no
>>> point
>>> in making suggestions? I am getting sick of this insulting attitude that
>>> is
>>> way too prevalent in open source communities.
>>>
>> I didn't say no point.  But repeating the same suggestion over and
>> over and over and over again, with no code is rather pointless.
>
>
> Discussing an issue about the upcoming release is not making the same
> suggestion repeatedly.
>
> Again your "with no code" comment is condescending and insulting.
>
>
>>> Do you want suggestions from anyone other than developers? If so, change
>>> your attitude.
>>>
>> Personally, I want bug reports more than suggestions right now.  But
>> code that fixes bugs is golden.
>
>
> In other words you don't want any suggestions that are contrary to your
> opinion
>

I'll put it to you quickly simple.  If you have been paying attention
you will realize that we're discussing release blocking issues.  Those
are the only changes we're making right now.  Release blocking issues
are issues in BZ that have the 3.4 release blocking issue flag set.
You are welcome to add such an issue if you think one is lacking.  You
can suggest things until you turn blue in the face and it will not
accomplish as much as the simple act of entering an issue once in BZ.

But I remind you that the fact that extensions will need to be
reinstalled in 3.4 is something that has been well-known in this
project for nearly 6 months now.  But no one has cared to do anything
about it.  And no one has raised it as release blocking issue, not
even as of today.

-Rob

>
>
> --
> _________________________________
>
> 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
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 2:29 PM  Rob Weir wrote:
> On Mon, Mar 5, 2012 at 3:19 PM, Larry Gusaas<la...@gmail.com>  wrote:
>> On 2012-03-05 1:44 PM  Rob Weir wrote:
>>> Again, your opinion carries as far as your willingness to code an
>>> alternative install approach.
>> Are you saying that unless one is willing to provide code there is no point
>> in making suggestions? I am getting sick of this insulting attitude that is
>> way too prevalent in open source communities.
>>
> I didn't say no point.  But repeating the same suggestion over and
> over and over and over again, with no code is rather pointless.

Discussing an issue about the upcoming release is not making the same suggestion repeatedly.

Again your "with no code" comment is condescending and insulting.

>> Do you want suggestions from anyone other than developers? If so, change
>> your attitude.
>>
> Personally, I want bug reports more than suggestions right now.  But
> code that fixes bugs is golden.

In other words you don't want any suggestions that are contrary to your opinion


-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 3:19 PM, Larry Gusaas <la...@gmail.com> wrote:
> On 2012-03-05 1:44 PM  Rob Weir wrote:
>>
>> Again, your opinion carries as far as your willingness to code an
>> alternative install approach.
>
>
> Are you saying that unless one is willing to provide code there is no point
> in making suggestions? I am getting sick of this insulting attitude that is
> way too prevalent in open source communities.
>

I didn't say no point.  But repeating the same suggestion over and
over and over and over again, with no code is rather pointless.

> Do you want suggestions from anyone other than developers? If so, change
> your attitude.
>

Personally, I want bug reports more than suggestions right now.  But
code that fixes bugs is golden.

-Rob

>
> --
> _________________________________
>
> 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
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Dave Fisher <da...@comcast.net>.
On Mar 5, 2012, at 12:19 PM, Larry Gusaas wrote:

> On 2012-03-05 1:44 PM  Rob Weir wrote:
>> Again, your opinion carries as far as your willingness to code an
>> alternative install approach.
> 
> Are you saying that unless one is willing to provide code there is no point in making suggestions? I am getting sick of this insulting attitude that is way too prevalent in open source communities.
> 
> Do you want suggestions from anyone other than developers? If so, change your attitude.

Larry - Thank you! Keep the suggestions coming.

Regards,
Dave


> 
> -- 
> _________________________________
> 
> 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
> 
> 


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 1:44 PM  Rob Weir wrote:
> Again, your opinion carries as far as your willingness to code an
> alternative install approach.

Are you saying that unless one is willing to provide code there is no point in making 
suggestions? I am getting sick of this insulting attitude that is way too prevalent in open 
source communities.

Do you want suggestions from anyone other than developers? If so, change your attitude.

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 1:24 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> It is one thing to encourage users to remove their older versions.
>
> It is another thing to automatically remove them and, along with that, features that they are relying upon.
>
> I don't think the ability of OO.o to replace versions in the same line (i.e., 3.* -- and 3.* did not remove 2.* and 1.* as far as I know) is the proper precedent.  I think how LibreOffice endeavored not to do that with their first and subsequent releases is the proper precedent.  This is not about wearing the crown, it is about serving the user community.
>

Again, your opinion carries as far as your willingness to code an
alternative install approach.

-Rob


>  - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Monday, March 05, 2012 10:09
> To: ooo-dev@incubator.apache.org
> Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)
>
> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>
>
> In general, it is important for OOo 3.3 and earlier installs on
> desktops to go away. Old releases increasingly become security
> hazards, especially if they are no longer being actively maintained.
> We do a great service to the community in general if we overwrite them
> with the AOO 3.4.  This is true even given the inconvenience the user
> experiences from the need to reinstall extensions.
>
> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
> OOo 3.2 did as well by default.  We can document in the install
> intructions how this can be overridden.
>
>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>>
>
> If you are volunteering to re-write the extension manager client
> database support, please speak up and let us know your plan.
>
>> I also suspect that it is not a good idea to rebrand the Extensions and Templates pages at SourceForge quite so strongly, since the only extensions that are there now are for OO.o (and perhaps LibreOffice).
>>
>>  - Dennis
>>
>> -----Original Message-----
>> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
>> Sent: Monday, March 05, 2012 02:06
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Calling all volunteers: It is time to test
>>
>> On 3/2/12 6:38 PM, Larry Gusaas wrote:
>>> On 2012-02-29 8:18 AM Rob Weir wrote:
>>>> Once you have installed, launch OpenOffice and look at the Help/About
>>>> box. If the revision shown there matches the build you installed
>>>> (e..g, "r1293550") then the install was a success. Please send a short
>>>> note to theooo-dev@incubator.apache.org telling us what platform and
>>>> scenario you installed (fresh install, upgrade, install next to
>>>> LibreOffice, etc.). This will help us understand what scenarios have
>>>> already been attempted and which have not.
>>>
>>> Using MacBook with OS X version 10.6.8
>>>
>>> Downloaded OOo_3.4.0_MacOS_x86_install_en-US.dmg
>>> Successfully installed replacing installation of OOo 3.3
>>>
>>> Installation deleted all of the extensions in my user profile. Quit OOo
>>> and replaced extension folder in my profile from my backup copy.
>>> Restarted OOo 3.4 and extensions deleted again. Will try installed
>>> individual extensions later today.
>>
>> Hi Larry,
>>
>> unfortunately extensions get lost because of the dropped Berkeley DB
>> which was used to manage installed extensions. We haven't found a simple
>> solution to migrate it. This will be documented in the release notes.
>>
>> Sorry
>>
>> Juergen
>>
>>
>>>
>>> All .odt files I opened worked. Was able to work with and save in
>>> Writer. The one database I have works. Will do further testing later.
>>>
>>
>

RE: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by "Dennis E. Hamilton" <de...@acm.org>.
It is one thing to encourage users to remove their older versions.

It is another thing to automatically remove them and, along with that, features that they are relying upon.

I don't think the ability of OO.o to replace versions in the same line (i.e., 3.* -- and 3.* did not remove 2.* and 1.* as far as I know) is the proper precedent.  I think how LibreOffice endeavored not to do that with their first and subsequent releases is the proper precedent.  This is not about wearing the crown, it is about serving the user community.  

 - Dennis

-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org] 
Sent: Monday, March 05, 2012 10:09
To: ooo-dev@incubator.apache.org
Subject: Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>

In general, it is important for OOo 3.3 and earlier installs on
desktops to go away. Old releases increasingly become security
hazards, especially if they are no longer being actively maintained.
We do a great service to the community in general if we overwrite them
with the AOO 3.4.  This is true even given the inconvenience the user
experiences from the need to reinstall extensions.

In any case, I think the overwrite is fine.  It is what OOo 3.3 and
OOo 3.2 did as well by default.  We can document in the install
intructions how this can be overridden.

> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>

If you are volunteering to re-write the extension manager client
database support, please speak up and let us know your plan.

> I also suspect that it is not a good idea to rebrand the Extensions and Templates pages at SourceForge quite so strongly, since the only extensions that are there now are for OO.o (and perhaps LibreOffice).
>
>  - Dennis
>
> -----Original Message-----
> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
> Sent: Monday, March 05, 2012 02:06
> To: ooo-dev@incubator.apache.org
> Subject: Re: Calling all volunteers: It is time to test
>
> On 3/2/12 6:38 PM, Larry Gusaas wrote:
>> On 2012-02-29 8:18 AM Rob Weir wrote:
>>> Once you have installed, launch OpenOffice and look at the Help/About
>>> box. If the revision shown there matches the build you installed
>>> (e..g, "r1293550") then the install was a success. Please send a short
>>> note to theooo-dev@incubator.apache.org telling us what platform and
>>> scenario you installed (fresh install, upgrade, install next to
>>> LibreOffice, etc.). This will help us understand what scenarios have
>>> already been attempted and which have not.
>>
>> Using MacBook with OS X version 10.6.8
>>
>> Downloaded OOo_3.4.0_MacOS_x86_install_en-US.dmg
>> Successfully installed replacing installation of OOo 3.3
>>
>> Installation deleted all of the extensions in my user profile. Quit OOo
>> and replaced extension folder in my profile from my backup copy.
>> Restarted OOo 3.4 and extensions deleted again. Will try installed
>> individual extensions later today.
>
> Hi Larry,
>
> unfortunately extensions get lost because of the dropped Berkeley DB
> which was used to manage installed extensions. We haven't found a simple
> solution to migrate it. This will be documented in the release notes.
>
> Sorry
>
> Juergen
>
>
>>
>> All .odt files I opened worked. Was able to work with and save in
>> Writer. The one database I have works. Will do further testing later.
>>
>


Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 3:07 PM, Jean Weber <je...@gmail.com> wrote:
> On Tue, Mar 6, 2012 at 05:46, Rob Weir <ro...@apache.org> wrote:
>> On Mon, Mar 5, 2012 at 2:37 PM, Jean Weber <je...@gmail.com> wrote:
>>> On 06/03/2012, at 4:30, Larry Gusaas <la...@gmail.com> wrote:
>>>
>>>> On 2012-03-05 12:08 PM  Rob Weir wrote:
>>>>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>>>>> <de...@acm.org>  wrote:
>>>>>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>>>>>
>>>>> In general, it is important for OOo 3.3 and earlier installs on
>>>>> desktops to go away. Old releases increasingly become security
>>>>> hazards, especially if they are no longer being actively maintained.
>>>>> We do a great service to the community in general if we overwrite them
>>>>> with the AOO 3.4.  This is true even given the inconvenience the user
>>>>> experiences from the need to reinstall extensions.
>>>>
>>>> Users need to be informed that they will need to reinstall extensions if AOO 3.4 overwrites OOo3.x.x
>>>>
>>>> One option would be to not use the same user profile as OOo 3.x.x and create a new profile for AOO 3.4. Or do as LibreOffice did when it came out and import the data that can be used from the OOo user profile into a new profile.
>>>>
>>>>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>>>>> OOo 3.2 did as well by default.  We can document in the install
>>>>> intructions how this can be overridden.
>>>>
>>>> The warning would have to be on the download page before the download link. How many current users of OOo actually read the install instructions before installing a new version?
>>>>
>>>>>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>>>> Agree
>>>>
>>>
>>> Rob,
>>>
>>> When an installation wipes out some or all of the user's extensions or other customisations of a previous version, that is a sure way to alienate a LOT of people and create a lot of very bad publicity, in addition to the inconvenience to users. I agree with Dennis and Larry that this is unacceptable. Indeed, I am very dismayed that anyone would seriously consider doing that. And documenting the issue, while necessary, is far from sufficient. Most people don't read the instructions, as you should know.
>>>
>>
>> I'm not aware of "other customizations" being overwritten in this
>> case. Can you say more?
>>
>> -Rob
>>
>>> Jean
>
> Generic statement, intended to cover other possibilities of which I
> might not be aware.
>

OK.  If you come across anything specific, please enter an issue in
BZ.  But for sake of a reasonable debate on the specific install
question in this thread, I'd recommend we not bring up hypothetical
issues that you are not actually aware of.

-Rob

> --Jean

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 3:26 PM, Jean Weber <je...@gmail.com> wrote:
> On Tue, Mar 6, 2012 at 06:07, Jean Weber <je...@gmail.com> wrote:
>> On Tue, Mar 6, 2012 at 05:46, Rob Weir <ro...@apache.org> wrote:
>>> On Mon, Mar 5, 2012 at 2:37 PM, Jean Weber <je...@gmail.com> wrote:
>>>> On 06/03/2012, at 4:30, Larry Gusaas <la...@gmail.com> wrote:
>>>>
>>>>> On 2012-03-05 12:08 PM  Rob Weir wrote:
>>>>>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>>>>>> <de...@acm.org>  wrote:
>>>>>>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>>>>>>
>>>>>> In general, it is important for OOo 3.3 and earlier installs on
>>>>>> desktops to go away. Old releases increasingly become security
>>>>>> hazards, especially if they are no longer being actively maintained.
>>>>>> We do a great service to the community in general if we overwrite them
>>>>>> with the AOO 3.4.  This is true even given the inconvenience the user
>>>>>> experiences from the need to reinstall extensions.
>>>>>
>>>>> Users need to be informed that they will need to reinstall extensions if AOO 3.4 overwrites OOo3.x.x
>>>>>
>>>>> One option would be to not use the same user profile as OOo 3.x.x and create a new profile for AOO 3.4. Or do as LibreOffice did when it came out and import the data that can be used from the OOo user profile into a new profile.
>>>>>
>>>>>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>>>>>> OOo 3.2 did as well by default.  We can document in the install
>>>>>> intructions how this can be overridden.
>>>>>
>>>>> The warning would have to be on the download page before the download link. How many current users of OOo actually read the install instructions before installing a new version?
>>>>>
>>>>>>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>>>>> Agree
>>>>>
>>>>
>>>> Rob,
>>>>
>>>> When an installation wipes out some or all of the user's extensions or other customisations of a previous version, that is a sure way to alienate a LOT of people and create a lot of very bad publicity, in addition to the inconvenience to users. I agree with Dennis and Larry that this is unacceptable. Indeed, I am very dismayed that anyone would seriously consider doing that. And documenting the issue, while necessary, is far from sufficient. Most people don't read the instructions, as you should know.
>>>>
>>>
>>> I'm not aware of "other customizations" being overwritten in this
>>> case. Can you say more?
>>>
>>> -Rob
>>>
>>
>> Generic statement, intended to cover other possibilities of which I
>> might not be aware.
>
>
> I note that you have ignored the real issue in my previous note:
> alienating users. I would like to hear how you expect or intend to
> deal with that.
>

I don't equate any amount of user inconvenience with "alienating
users."  To suggest this is pure hyperbole, divorced from reality.
Microsoft breaks their plugins with every release and requires
reinstall.  They seem to manage to preserve a non-negligible market
share. Many programs do this.  Some do better, some check for
compatibility and enable some but not all extensions.  I suppose if
the Mozilla developers said that they had to bread the compatibility
checking code in a release, that some project members might resort to
hyperbole about alienating users and say that it was unacceptable.
But not that their unacceptable solution is just life as usual for
OpenOffice, since we don't do compatibility checks on upgrade.   And
what you call unacceptable in OpenOffice is just life as usual for MS
Office.

A little perspective goes a long way.  This is not the end of the
world.  Not even close.  I recommend dealing with it with user
education.

-Rob

> --Jean

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Jean Weber <je...@gmail.com>.
On Tue, Mar 6, 2012 at 06:07, Jean Weber <je...@gmail.com> wrote:
> On Tue, Mar 6, 2012 at 05:46, Rob Weir <ro...@apache.org> wrote:
>> On Mon, Mar 5, 2012 at 2:37 PM, Jean Weber <je...@gmail.com> wrote:
>>> On 06/03/2012, at 4:30, Larry Gusaas <la...@gmail.com> wrote:
>>>
>>>> On 2012-03-05 12:08 PM  Rob Weir wrote:
>>>>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>>>>> <de...@acm.org>  wrote:
>>>>>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>>>>>
>>>>> In general, it is important for OOo 3.3 and earlier installs on
>>>>> desktops to go away. Old releases increasingly become security
>>>>> hazards, especially if they are no longer being actively maintained.
>>>>> We do a great service to the community in general if we overwrite them
>>>>> with the AOO 3.4.  This is true even given the inconvenience the user
>>>>> experiences from the need to reinstall extensions.
>>>>
>>>> Users need to be informed that they will need to reinstall extensions if AOO 3.4 overwrites OOo3.x.x
>>>>
>>>> One option would be to not use the same user profile as OOo 3.x.x and create a new profile for AOO 3.4. Or do as LibreOffice did when it came out and import the data that can be used from the OOo user profile into a new profile.
>>>>
>>>>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>>>>> OOo 3.2 did as well by default.  We can document in the install
>>>>> intructions how this can be overridden.
>>>>
>>>> The warning would have to be on the download page before the download link. How many current users of OOo actually read the install instructions before installing a new version?
>>>>
>>>>>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>>>> Agree
>>>>
>>>
>>> Rob,
>>>
>>> When an installation wipes out some or all of the user's extensions or other customisations of a previous version, that is a sure way to alienate a LOT of people and create a lot of very bad publicity, in addition to the inconvenience to users. I agree with Dennis and Larry that this is unacceptable. Indeed, I am very dismayed that anyone would seriously consider doing that. And documenting the issue, while necessary, is far from sufficient. Most people don't read the instructions, as you should know.
>>>
>>
>> I'm not aware of "other customizations" being overwritten in this
>> case. Can you say more?
>>
>> -Rob
>>
>
> Generic statement, intended to cover other possibilities of which I
> might not be aware.


I note that you have ignored the real issue in my previous note:
alienating users. I would like to hear how you expect or intend to
deal with that.

--Jean

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Jean Weber <je...@gmail.com>.
On Tue, Mar 6, 2012 at 05:46, Rob Weir <ro...@apache.org> wrote:
> On Mon, Mar 5, 2012 at 2:37 PM, Jean Weber <je...@gmail.com> wrote:
>> On 06/03/2012, at 4:30, Larry Gusaas <la...@gmail.com> wrote:
>>
>>> On 2012-03-05 12:08 PM  Rob Weir wrote:
>>>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>>>> <de...@acm.org>  wrote:
>>>>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>>>>
>>>> In general, it is important for OOo 3.3 and earlier installs on
>>>> desktops to go away. Old releases increasingly become security
>>>> hazards, especially if they are no longer being actively maintained.
>>>> We do a great service to the community in general if we overwrite them
>>>> with the AOO 3.4.  This is true even given the inconvenience the user
>>>> experiences from the need to reinstall extensions.
>>>
>>> Users need to be informed that they will need to reinstall extensions if AOO 3.4 overwrites OOo3.x.x
>>>
>>> One option would be to not use the same user profile as OOo 3.x.x and create a new profile for AOO 3.4. Or do as LibreOffice did when it came out and import the data that can be used from the OOo user profile into a new profile.
>>>
>>>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>>>> OOo 3.2 did as well by default.  We can document in the install
>>>> intructions how this can be overridden.
>>>
>>> The warning would have to be on the download page before the download link. How many current users of OOo actually read the install instructions before installing a new version?
>>>
>>>>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>>> Agree
>>>
>>
>> Rob,
>>
>> When an installation wipes out some or all of the user's extensions or other customisations of a previous version, that is a sure way to alienate a LOT of people and create a lot of very bad publicity, in addition to the inconvenience to users. I agree with Dennis and Larry that this is unacceptable. Indeed, I am very dismayed that anyone would seriously consider doing that. And documenting the issue, while necessary, is far from sufficient. Most people don't read the instructions, as you should know.
>>
>
> I'm not aware of "other customizations" being overwritten in this
> case. Can you say more?
>
> -Rob
>
>> Jean

Generic statement, intended to cover other possibilities of which I
might not be aware.

--Jean

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 2:37 PM, Jean Weber <je...@gmail.com> wrote:
> On 06/03/2012, at 4:30, Larry Gusaas <la...@gmail.com> wrote:
>
>> On 2012-03-05 12:08 PM  Rob Weir wrote:
>>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>>> <de...@acm.org>  wrote:
>>>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>>>
>>> In general, it is important for OOo 3.3 and earlier installs on
>>> desktops to go away. Old releases increasingly become security
>>> hazards, especially if they are no longer being actively maintained.
>>> We do a great service to the community in general if we overwrite them
>>> with the AOO 3.4.  This is true even given the inconvenience the user
>>> experiences from the need to reinstall extensions.
>>
>> Users need to be informed that they will need to reinstall extensions if AOO 3.4 overwrites OOo3.x.x
>>
>> One option would be to not use the same user profile as OOo 3.x.x and create a new profile for AOO 3.4. Or do as LibreOffice did when it came out and import the data that can be used from the OOo user profile into a new profile.
>>
>>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>>> OOo 3.2 did as well by default.  We can document in the install
>>> intructions how this can be overridden.
>>
>> The warning would have to be on the download page before the download link. How many current users of OOo actually read the install instructions before installing a new version?
>>
>>>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>> Agree
>>
>
> Rob,
>
> When an installation wipes out some or all of the user's extensions or other customisations of a previous version, that is a sure way to alienate a LOT of people and create a lot of very bad publicity, in addition to the inconvenience to users. I agree with Dennis and Larry that this is unacceptable. Indeed, I am very dismayed that anyone would seriously consider doing that. And documenting the issue, while necessary, is far from sufficient. Most people don't read the instructions, as you should know.
>

I'm not aware of "other customizations" being overwritten in this
case. Can you say more?

-Rob

> Jean

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Jean Weber <je...@gmail.com>.
On 06/03/2012, at 4:30, Larry Gusaas <la...@gmail.com> wrote:

> On 2012-03-05 12:08 PM  Rob Weir wrote:
>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>> <de...@acm.org>  wrote:
>>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>> 
>> In general, it is important for OOo 3.3 and earlier installs on
>> desktops to go away. Old releases increasingly become security
>> hazards, especially if they are no longer being actively maintained.
>> We do a great service to the community in general if we overwrite them
>> with the AOO 3.4.  This is true even given the inconvenience the user
>> experiences from the need to reinstall extensions.
> 
> Users need to be informed that they will need to reinstall extensions if AOO 3.4 overwrites OOo3.x.x
> 
> One option would be to not use the same user profile as OOo 3.x.x and create a new profile for AOO 3.4. Or do as LibreOffice did when it came out and import the data that can be used from the OOo user profile into a new profile.
> 
>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>> OOo 3.2 did as well by default.  We can document in the install
>> intructions how this can be overridden.
> 
> The warning would have to be on the download page before the download link. How many current users of OOo actually read the install instructions before installing a new version?
> 
>>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
> Agree
> 

Rob, 

When an installation wipes out some or all of the user's extensions or other customisations of a previous version, that is a sure way to alienate a LOT of people and create a lot of very bad publicity, in addition to the inconvenience to users. I agree with Dennis and Larry that this is unacceptable. Indeed, I am very dismayed that anyone would seriously consider doing that. And documenting the issue, while necessary, is far from sufficient. Most people don't read the instructions, as you should know. 

Jean

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 1:52 PM  Rob Weir wrote:
> On Mon, Mar 5, 2012 at 1:30 PM, Larry Gusaas<la...@gmail.com>  wrote:
>> On 2012-03-05 12:08 PM  Rob Weir wrote:
>>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>>> <de...@acm.org>    wrote:
>>>> If there is no solution for extensions, Apache OpenOffice 3.4 early
>>>> incubator releases should not overload prior versions of OO.o.  I recommend
>>>> that AOO 3.4 install in its own locations and not do anything that would
>>>> prevent side-by-side functioning.  (My recommendation would be that it do
>>>> that anyhow.  But with known breaking of an important down-level feature,
>>>> that becomes imperative.)
>>>>
>>> In general, it is important for OOo 3.3 and earlier installs on
>>> desktops to go away. Old releases increasingly become security
>>> hazards, especially if they are no longer being actively maintained.
>>> We do a great service to the community in general if we overwrite them
>>> with the AOO 3.4.  This is true even given the inconvenience the user
>>> experiences from the need to reinstall extensions.
>> Users need to be informed that they will need to reinstall extensions if AOO
>> 3.4 overwrites OOo3.x.x
>>
> Yes.  But note that this will also be true if we installed AOO into a
> different directory.  They would need to reinstall all the extensions
> again also.

That is pretty obvious. What is your point?

>> One option would be to not use the same user profile as OOo 3.x.x and create
>> a new profile for AOO 3.4. Or do as LibreOffice did when it came out and
>> import the data that can be used from the OOo user profile into a new
>> profile.
>>
> That won't help in this case.  Regardless of where the profile is
> stored, we're unable to read the local DB that stored information
> about what extensions were installed.  So whether we use the same
> profile or not, the user still must reinstall extensions if they want
> them to work in AOO 3.4.

Yes it would. Importing the data that can be used in AOO 3.4 would leave the OOo user profile 
intact. If the user then continues to use OOo their user profile would be intact. The user 
would only have to install the extensions instead of redoing all user preferences, 
dictionaries, templates, etc.

>>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>>> OOo 3.2 did as well by default.  We can document in the install
>>> intructions how this can be overridden.
>> The warning would have to be on the download page before the download link.
>> How many current users of OOo actually read the install instructions before
>> installing a new version?
>>
> If the user's goal is to continue running OOo 3.3.0, then what can we
> say?  Don't install AOO 3.4 or 4.0, or 5.0, etc.    But if they do
> want to run AOO 3.4 then they will need to reinstall the extensions.
> I haven't heard anyone suggest an alternative approach to solving that
> problem.

I have suggested an alternative that leaves the OOo profile intact.

> Of course, "patches are welcome".

I am not a programmer. Such suggestions to users are insulting. Do you want our feedback?


-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 1:30 PM, Larry Gusaas <la...@gmail.com> wrote:
> On 2012-03-05 12:08 PM  Rob Weir wrote:
>>
>> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
>> <de...@acm.org>  wrote:
>>>
>>> If there is no solution for extensions, Apache OpenOffice 3.4 early
>>> incubator releases should not overload prior versions of OO.o.  I recommend
>>> that AOO 3.4 install in its own locations and not do anything that would
>>> prevent side-by-side functioning.  (My recommendation would be that it do
>>> that anyhow.  But with known breaking of an important down-level feature,
>>> that becomes imperative.)
>>>
>> In general, it is important for OOo 3.3 and earlier installs on
>> desktops to go away. Old releases increasingly become security
>> hazards, especially if they are no longer being actively maintained.
>> We do a great service to the community in general if we overwrite them
>> with the AOO 3.4.  This is true even given the inconvenience the user
>> experiences from the need to reinstall extensions.
>
>
> Users need to be informed that they will need to reinstall extensions if AOO
> 3.4 overwrites OOo3.x.x
>

Yes.  But note that this will also be true if we installed AOO into a
different directory.  They would need to reinstall all the extensions
again also.

> One option would be to not use the same user profile as OOo 3.x.x and create
> a new profile for AOO 3.4. Or do as LibreOffice did when it came out and
> import the data that can be used from the OOo user profile into a new
> profile.
>

That won't help in this case.  Regardless of where the profile is
stored, we're unable to read the local DB that stored information
about what extensions were installed.  So whether we use the same
profile or not, the user still must reinstall extensions if they want
them to work in AOO 3.4.

>
>> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
>> OOo 3.2 did as well by default.  We can document in the install
>> intructions how this can be overridden.
>
>
> The warning would have to be on the download page before the download link.
> How many current users of OOo actually read the install instructions before
> installing a new version?
>

If the user's goal is to continue running OOo 3.3.0, then what can we
say?  Don't install AOO 3.4 or 4.0, or 5.0, etc.    But if they do
want to run AOO 3.4 then they will need to reinstall the extensions.
I haven't heard anyone suggest an alternative approach to solving that
problem.  Of course, "patches are welcome".

>
>>> I think there should be OOo-dev releases only until this is handled as
>>> well.  It is now clear that integration has problems and there is no reason
>>> to provoke more of it.
>
> Agree
>
> --
> _________________________________
>
> 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
>
>

Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Larry Gusaas <la...@gmail.com>.
On 2012-03-05 12:08 PM  Rob Weir wrote:
> On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
> <de...@acm.org>  wrote:
>> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>>
> In general, it is important for OOo 3.3 and earlier installs on
> desktops to go away. Old releases increasingly become security
> hazards, especially if they are no longer being actively maintained.
> We do a great service to the community in general if we overwrite them
> with the AOO 3.4.  This is true even given the inconvenience the user
> experiences from the need to reinstall extensions.

Users need to be informed that they will need to reinstall extensions if AOO 3.4 overwrites 
OOo3.x.x

One option would be to not use the same user profile as OOo 3.x.x and create a new profile for 
AOO 3.4. Or do as LibreOffice did when it came out and import the data that can be used from 
the OOo user profile into a new profile.

> In any case, I think the overwrite is fine.  It is what OOo 3.3 and
> OOo 3.2 did as well by default.  We can document in the install
> intructions how this can be overridden.

The warning would have to be on the download page before the download link. How many current 
users of OOo actually read the install instructions before installing a new version?

>> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
Agree

-- 
_________________________________

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



Re: [EXTENSIONS][RELEASE] (was RE: Calling all volunteers: It is time to test)

Posted by Rob Weir <ro...@apache.org>.
On Mon, Mar 5, 2012 at 12:29 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> If there is no solution for extensions, Apache OpenOffice 3.4 early incubator releases should not overload prior versions of OO.o.  I recommend that AOO 3.4 install in its own locations and not do anything that would prevent side-by-side functioning.  (My recommendation would be that it do that anyhow.  But with known breaking of an important down-level feature, that becomes imperative.)
>

In general, it is important for OOo 3.3 and earlier installs on
desktops to go away. Old releases increasingly become security
hazards, especially if they are no longer being actively maintained.
We do a great service to the community in general if we overwrite them
with the AOO 3.4.  This is true even given the inconvenience the user
experiences from the need to reinstall extensions.

In any case, I think the overwrite is fine.  It is what OOo 3.3 and
OOo 3.2 did as well by default.  We can document in the install
intructions how this can be overridden.

> I think there should be OOo-dev releases only until this is handled as well.  It is now clear that integration has problems and there is no reason to provoke more of it.
>

If you are volunteering to re-write the extension manager client
database support, please speak up and let us know your plan.

> I also suspect that it is not a good idea to rebrand the Extensions and Templates pages at SourceForge quite so strongly, since the only extensions that are there now are for OO.o (and perhaps LibreOffice).
>
>  - Dennis
>
> -----Original Message-----
> From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
> Sent: Monday, March 05, 2012 02:06
> To: ooo-dev@incubator.apache.org
> Subject: Re: Calling all volunteers: It is time to test
>
> On 3/2/12 6:38 PM, Larry Gusaas wrote:
>> On 2012-02-29 8:18 AM Rob Weir wrote:
>>> Once you have installed, launch OpenOffice and look at the Help/About
>>> box. If the revision shown there matches the build you installed
>>> (e..g, "r1293550") then the install was a success. Please send a short
>>> note to theooo-dev@incubator.apache.org telling us what platform and
>>> scenario you installed (fresh install, upgrade, install next to
>>> LibreOffice, etc.). This will help us understand what scenarios have
>>> already been attempted and which have not.
>>
>> Using MacBook with OS X version 10.6.8
>>
>> Downloaded OOo_3.4.0_MacOS_x86_install_en-US.dmg
>> Successfully installed replacing installation of OOo 3.3
>>
>> Installation deleted all of the extensions in my user profile. Quit OOo
>> and replaced extension folder in my profile from my backup copy.
>> Restarted OOo 3.4 and extensions deleted again. Will try installed
>> individual extensions later today.
>
> Hi Larry,
>
> unfortunately extensions get lost because of the dropped Berkeley DB
> which was used to manage installed extensions. We haven't found a simple
> solution to migrate it. This will be documented in the release notes.
>
> Sorry
>
> Juergen
>
>
>>
>> All .odt files I opened worked. Was able to work with and save in
>> Writer. The one database I have works. Will do further testing later.
>>
>