On Mar 5, 2012, at 2:38 PM, Rob Weir wrote: > On Mon, Mar 5, 2012 at 5:15 PM, Larry Gusaas <[email protected]> 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 [email protected] 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 >> >>
