Re: Test for unsubscribe link

[Issac Goldstand]

It's in the headers.  All apache.org lists are like that.

On 29/12/2012 16:03, Andrea Pescetti wrote:

Peter Junge wrote:

There's indeed no unsubscribe link coming with my email. Does anyone
know if this is intended or is it a bug?


I can't find any older messages to ooo-dev that include an unsubscribe 
link, or a footer in general. Configuring a footer is something that, 
as far as I know, only Infra can do, and you can find an example at

https://issues.apache.org/jira/browse/INFRA-4512

I would find it useful to have at least the "basic" footer 
(unsubscribe+help) added to all our international public lists listed 
at http://openoffice.apache.org/mailing-lists.html unless they already 
have one.


Regards,
  Andrea.

Re: Test for unsubscribe link

[Peter Junge]

On 12/30/2012 4:37 PM, Issac Goldstand wrote:

It's in the headers.  All apache.org lists are like that.


Yes, I noticed that, but with OpenOffice we need to consider that it's 
an end user software, so we have typical end users subscribed to our 
mailing list, especially with users@. These guys need to find the 
information to unsubscribe easily.


Peter



On 29/12/2012 16:03, Andrea Pescetti wrote:

Peter Junge wrote:

There's indeed no unsubscribe link coming with my email. Does anyone
know if this is intended or is it a bug?


I can't find any older messages to ooo-dev that include an unsubscribe
link, or a footer in general. Configuring a footer is something that,
as far as I know, only Infra can do, and you can find an example at
https://issues.apache.org/jira/browse/INFRA-4512

I would find it useful to have at least the "basic" footer
(unsubscribe+help) added to all our international public lists listed
at http://openoffice.apache.org/mailing-lists.html unless they already
have one.

Regards,
  Andrea.

Draft: Guidelines for redistributing (an original) Apache OpenOffice with 3rd party bundles (e.g. books or template packages)

[Peter Junge]

Hi,

from time to time there are requests to bundle OpenOffice with 3rd party 
products. A typical case is that a publishing house wants to release a 
commercial box in which they bundle an original version of Apache 
OpenOffice with a handbook (either printed or electronic) and some 
goodies like a pack of templates. As I'm expecting such cases will 
pop-up frequently (mostly at private@, hence they're not too visible 
here), it would be good to have some guidelines in place. I have drafted 
some, please review and comment. The result is intended to be submitted 
as a proposal here and should go on our website later.


Happy New Year
Peter

-

=== Guidelines for redistributing (an original) Apache OpenOffice with 
3rd party bundles ===


1) You must solely use an unmodified binary version of Apache OpenOffice 
that can be downloaded by anyone from 
http://www.openoffice.org/download/index.html. If you build your own 
product from the Apache OpenOffice sources, then you must give your 
product a different name that must not be confused with Apache 
OpenOffice. Under certain circumstances, you may then use 'Powered by 
Apache OpenOffice'. For details, please refer:

http://www.apache.org/foundation/marks/faq/#poweredby

2) You must always use the proper name 'Apache OpenOffice x[.y[.z]]' 
(e.g. 3.4.1) for our product. IMPORTANT: Do NOT use 'Apache Open Office' 
or 'Apache OpenOffice.org' or 'OpenOffice' or 'Open Office' or 
'OpenOffice.org' etc.


3) Do not use any additions to 'Apache OpenOffice x.y.z' with the title 
of your bundle that imply that you are shipping a product which is 
superior to Apache OpenOffice, e.g. you must not use a title like 
'Apache OpenOffice 3.4.1 Professional'. You may rather use the title 
'Apache OpenOffice 3.4.1' with a subtitle like '{YOUR_BRAND} 
Professional Pack' because you have added value to an original Apache 
OpenOffice.


4) If you want to use the Apache OpenOffice logo on your bundle, you 
must solely use the original, unmodified Apache OpenOffice logo:

https://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/images/AOO_logos/svg/OOo_Website_v2_copy.svg

5) You must attribute the Apache Software Foundation and it's trademarks 
with all components of your bundle (e.g. Cover, Box, printed Book, 
electronic book, CD/DVD etc.). A proper attribution is:

---
"Apache",[ the “Apache logo”,] "Apache OpenOffice", "OpenOffice" and the 
“Apache OpenOffice logo” are trademarks of the Apache Software 
Foundation (http://www.apache.org)

---
For the detailed Apache Trademark Policy, please refer: 
http://www.apache.org/foundation/marks/


6) You must make clear with all components of your bundle (e.g. Cover, 
Box, printed Book, electronic book, CD/DVD etc.) that you are providing 
an unmodified version of Apache OpenOffice with your bundle. A proper 
way to do that it adding an informative statement like:

---
"Includes the original Apache OpenOffice 3.4.1 as provided by the Apache 
Software Foundation under Apache License Version 2 at 
http://www.openoffice.org/download/";.

---

7) Your setup routine must clearly distinguish between installing Apache 
OpenOffice and the additional products of your bundle.


8) There may be exceptions to the guidelines as above, but they must be 
explicitly permitted by the Apache Software Foundation.


9) You must contact the Apache OpenOffice Project Management Committee 
at priv...@openoffice.apache.org before releasing your bundle so our 
community is able to review it. Please keep in mind that these are just 
guidelines and granting you the privilege to use 'Apache OpenOffice' 
with your bundle is at the sole discretion of the Apache Software 
Foundation on a case by case basis.

Re: Draft: Guidelines for redistributing (an original) Apache OpenOffice with 3rd party bundles (e.g. books or template packages)

[janI]

+1, I would add a line saying something:

In no case are such distributions allowed without the written consensus of
Apache OpenOffice.

That will make it easier to pursue a case, if someone just distributes. I
would also suggest, we add a link to the distribution guideline, so one can
claim "I did not know".

Jan I

On 30 December 2012 12:14, Peter Junge  wrote:

> Hi,
>
> from time to time there are requests to bundle OpenOffice with 3rd party
> products. A typical case is that a publishing house wants to release a
> commercial box in which they bundle an original version of Apache
> OpenOffice with a handbook (either printed or electronic) and some goodies
> like a pack of templates. As I'm expecting such cases will pop-up
> frequently (mostly at private@, hence they're not too visible here), it
> would be good to have some guidelines in place. I have drafted some, please
> review and comment. The result is intended to be submitted as a proposal
> here and should go on our website later.
>
> Happy New Year
> Peter
>
> -
>
> === Guidelines for redistributing (an original) Apache OpenOffice with 3rd
> party bundles ===
>
> 1) You must solely use an unmodified binary version of Apache OpenOffice
> that can be downloaded by anyone from http://www.openoffice.org/**
> download/index.html . If
> you build your own product from the Apache OpenOffice sources, then you
> must give your product a different name that must not be confused with
> Apache OpenOffice. Under certain circumstances, you may then use 'Powered
> by Apache OpenOffice'. For details, please refer:
> http://www.apache.org/**foundation/marks/faq/#**poweredby
>
> 2) You must always use the proper name 'Apache OpenOffice x[.y[.z]]' (e.g.
> 3.4.1) for our product. IMPORTANT: Do NOT use 'Apache Open Office' or
> 'Apache OpenOffice.org' or 'OpenOffice' or 'Open Office' or
> 'OpenOffice.org' etc.
>
> 3) Do not use any additions to 'Apache OpenOffice x.y.z' with the title of
> your bundle that imply that you are shipping a product which is superior to
> Apache OpenOffice, e.g. you must not use a title like 'Apache OpenOffice
> 3.4.1 Professional'. You may rather use the title 'Apache OpenOffice 3.4.1'
> with a subtitle like '{YOUR_BRAND} Professional Pack' because you have
> added value to an original Apache OpenOffice.
>
> 4) If you want to use the Apache OpenOffice logo on your bundle, you must
> solely use the original, unmodified Apache OpenOffice logo:
> https://svn.apache.org/repos/**asf/openoffice/ooo-site/trunk/**
> content/images/AOO_logos/svg/**OOo_Website_v2_copy.svg
>
> 5) You must attribute the Apache Software Foundation and it's trademarks
> with all components of your bundle (e.g. Cover, Box, printed Book,
> electronic book, CD/DVD etc.). A proper attribution is:
> ---
> "Apache",[ the “Apache logo”,] "Apache OpenOffice", "OpenOffice" and the
> “Apache OpenOffice logo” are trademarks of the Apache Software Foundation (
> http://www.apache.org)
> ---
> For the detailed Apache Trademark Policy, please refer:
> http://www.apache.org/**foundation/marks/
>
> 6) You must make clear with all components of your bundle (e.g. Cover,
> Box, printed Book, electronic book, CD/DVD etc.) that you are providing an
> unmodified version of Apache OpenOffice with your bundle. A proper way to
> do that it adding an informative statement like:
> ---
> "Includes the original Apache OpenOffice 3.4.1 as provided by the Apache
> Software Foundation under Apache License Version 2 at
> http://www.openoffice.org/**download/
> ".
> ---
>
> 7) Your setup routine must clearly distinguish between installing Apache
> OpenOffice and the additional products of your bundle.
>
> 8) There may be exceptions to the guidelines as above, but they must be
> explicitly permitted by the Apache Software Foundation.
>
> 9) You must contact the Apache OpenOffice Project Management Committee at
> priv...@openoffice.apache.org before releasing your bundle so our
> community is able to review it. Please keep in mind that these are just
> guidelines and granting you the privilege to use 'Apache OpenOffice' with
> your bundle is at the sole discretion of the Apache Software Foundation on
> a case by case basis.
>

Endnote/Index in Writer

[Rory O'Farrell]

On the en-Forum it has just been pointed out to me that Endnotes place 
themselves at the End of a document; this prevents an alphabetical Index being 
placed there, which is the usual location for it.  Perhaps this should be 
considered for alteration in a forthcoming revision of Writer.

-- 
Rory O'Farrell 

Re: Draft: Guidelines for redistributing (an original) Apache OpenOffice with 3rd party bundles (e.g. books or template packages)

[TJ Frazier]

On 12/30/2012 06:32, janI wrote:

+1, I would add a line saying something:

In no case are such distributions allowed without the written consensus of
Apache OpenOffice.

That will make it easier to pursue a case, if someone just distributes. I
would also suggest, we add a link to the distribution guideline, so one can
claim "I did not know".

Jan I

On 30 December 2012 12:14, Peter Junge  wrote:


Hi,

from time to time there are requests to bundle OpenOffice with 3rd party
products. A typical case is that a publishing house wants to release a
commercial box in which they bundle an original version of Apache
OpenOffice with a handbook (either printed or electronic) and some goodies
like a pack of templates. As I'm expecting such cases will pop-up
frequently (mostly at private@, hence they're not too visible here), it
would be good to have some guidelines in place. I have drafted some, please
review and comment. The result is intended to be submitted as a proposal
here and should go on our website later.

Happy New Year
Peter

-

=== Guidelines for redistributing (an original) Apache OpenOffice with 3rd
party bundles ===

1) You must solely use an unmodified binary version of Apache OpenOffice
that can be downloaded by anyone from http://www.openoffice.org/**
download/index.html . If
you build your own product from the Apache OpenOffice sources, then you
must give your product a different name that must not be confused with
Apache OpenOffice. Under certain circumstances, you may then use 'Powered
by Apache OpenOffice'. For details, please refer:
http://www.apache.org/**foundation/marks/faq/#**poweredby

2) You must always use the proper name 'Apache OpenOffice x[.y[.z]]' (e.g.
3.4.1) for our product. IMPORTANT: Do NOT use 'Apache Open Office' or
'Apache OpenOffice.org' or 'OpenOffice' or 'Open Office' or
'OpenOffice.org' etc.

3) Do not use any additions to 'Apache OpenOffice x.y.z' with the title of
your bundle that imply that you are shipping a product which is superior to
Apache OpenOffice, e.g. you must not use a title like 'Apache OpenOffice
3.4.1 Professional'. You may rather use the title 'Apache OpenOffice 3.4.1'
with a subtitle like '{YOUR_BRAND} Professional Pack' because you have
added value to an original Apache OpenOffice.

4) If you want to use the Apache OpenOffice logo on your bundle, you must
solely use the original, unmodified Apache OpenOffice logo:
https://svn.apache.org/repos/**asf/openoffice/ooo-site/trunk/**
content/images/AOO_logos/svg/**OOo_Website_v2_copy.svg

5) You must attribute the Apache Software Foundation and it's trademarks
with all components of your bundle (e.g. Cover, Box, printed Book,
electronic book, CD/DVD etc.). A proper attribution is:
---
"Apache",[ the “Apache logo”,] "Apache OpenOffice", "OpenOffice" and the
“Apache OpenOffice logo” are trademarks of the Apache Software Foundation (
http://www.apache.org)
---
For the detailed Apache Trademark Policy, please refer:
http://www.apache.org/**foundation/marks/

6) You must make clear with all components of your bundle (e.g. Cover,
Box, printed Book, electronic book, CD/DVD etc.) that you are providing an
unmodified version of Apache OpenOffice with your bundle. A proper way to
do that it adding an informative statement like:
---
"Includes the original Apache OpenOffice 3.4.1 as provided by the Apache
Software Foundation under Apache License Version 2 at
http://www.openoffice.org/**download/
".
---

7) Your setup routine must clearly distinguish between installing Apache
OpenOffice and the additional products of your bundle.

8) There may be exceptions to the guidelines as above, but they must be
explicitly permitted by the Apache Software Foundation.

9) You must contact the Apache OpenOffice Project Management Committee at
priv...@openoffice.apache.org before releasing your bundle so our
community is able to review it. Please keep in mind that these are just
guidelines and granting you the privilege to use 'Apache OpenOffice' with
your bundle is at the sole discretion of the Apache Software Foundation on
a case by case basis.



It wasn't altogether clear to me that the reference here was to the 
trademark, rather than to the code.


Incorporating Jan's suggestion and mine:

" ... granting you the privilege to use 'Apache OpenOffice™' or other 
ASF trademarks and logos with your bundle ... a case by case basis. In 
no case is such labeling of distributions allowed without the written 
consent of the ASF."


/tj/

Re: Endnote/Index in Writer

[TJ Frazier]

On 12/30/2012 07:11, Rory O'Farrell wrote:


On the en-Forum it has just been pointed out to me that Endnotes place 
themselves at the End of a document; this prevents an alphabetical Index being 
placed there, which is the usual location for it.  Perhaps this should be 
considered for alteration in a forthcoming revision of Writer.


Hi, Rory,

Would a "fake" master doc (only one sub-document) be a quick way around 
this problem? The endnotes should stay with the chapter, and the index, 
specified in the master, should come last. (I don't use these features, 
so I can't say for sure.)


HTH,
/tj/

Re: old business...old OpenOffice domain names registered by Oracle (primarily)

[Andrea Pescetti]

On 02/11/2012 Andrea Pescetti wrote:

Actually these domains are still there: I tested 5 random ones from
https://issues.apache.org/jira/browse/INFRA-4906 and as Dave wrote they
appear to have been (auto)renewed. They do not resolve, but WHOIS shows
that they still exist and still belong to Oracle.
Which means that https://issues.apache.org/jira/browse/INFRA-4906 can
progress normally with the transfer of ownership of those domains to the
ASF. I asked on the issue page details on the next steps.


I've seen no developments on this old issue. This is something that the 
project can only marginally control, since it requires a handover of the 
domain names from Oracle to r...@apache.org ; did the discussion between 
Oracle and root even start? Refer to the issue page (link above) for 
more information.


Regards,
  Andrea.

Re: Endnote/Index in Writer

[RGB ES]

2012/12/30 TJ Frazier 

> On 12/30/2012 07:11, Rory O'Farrell wrote:
>
>>
>> On the en-Forum it has just been pointed out to me that Endnotes place
>> themselves at the End of a document; this prevents an alphabetical Index
>> being placed there, which is the usual location for it.  Perhaps this
>> should be considered for alteration in a forthcoming revision of Writer.
>>
>>  Hi, Rory,
>
> Would a "fake" master doc (only one sub-document) be a quick way around
> this problem?


I don't think so. The only way to move endnotes from the end of the
document is to enclose the whole document/chapter on a section configured
to send the endnotes at the end of the section itself instead of the end of
the document. While this workaround covers most user cases, there could be
corner situations (a document already using lots of sections, for example
to get variable number of columns) where this will not work as intended.

Regards
Ricardo




> The endnotes should stay with the chapter, and the index, specified in the
> master, should come last. (I don't use these features, so I can't say for
> sure.)
>
> HTH,
> /tj/
>
>
>

Re: [RELEASE] Respin snapshot builds for early verification available

[Jeongkyu Kim]

On Fri, Dec 21, 2012 at 11:54 PM, Jürgen Schmidt wrote:

> Hi,
>
> before I go on Christmas vacation I have built snapshots for our
> upcoming AOO 3.4.1 respin to support further languages.
>
> I create a build for Danish, Swedish, Polish, Norwegian Bokmal, Scottish
> Gaelic and Korean.
>
>
Juergen,

Fortunately, Korean translation was completed in time. Would you let me
know how can I submit the po files? Actually, I sent you email several days
ago with the zipped po files as attachment, but it looks like being lost
somewhere. :-)

Jeongkyu
-- 
Jeongkyu Kim
OpenOffice.org Korean community lead

Community website http://openoffice.or.kr
Personal blog http://openoffice.or.kr/gomme

Re: [RELEASE] Respin snapshot builds for early verification available

[Andrea Pescetti]

Jeongkyu Kim wrote:

Fortunately, Korean translation was completed in time. Would you let me
know how can I submit the po files?


To follow the standard procedure, you should attach the zipped PO files 
to this issue I've just created:

https://issues.apache.org/ooo/show_bug.cgi?id=121559
(you will need to register an account for Bugzilla).

If the ZIP file is too big to be attached, specify just a link there or 
send the file to me in private and I'll update the issue. Please specify 
the names of all volunteers involved so that we can give them proper credit.



Actually, I sent you email several days
ago with the zipped po files as attachment, but it looks like being lost
somewhere. :-)


Then it's already in good hands... it's just holiday time in Europe (and 
elsewhere). But the procedure above is what we recommend, see

http://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Respin+for+additional+languages

If you have any further doubts or comments, just ask on the l10n list.

Regards,
  Andrea.

Re: Endnote/Index in Writer

[Rory O'Farrell]

On Sun, 30 Dec 2012 08:00:46 -0500
TJ Frazier  wrote:

> On 12/30/2012 07:11, Rory O'Farrell wrote:
> >
> > On the en-Forum it has just been pointed out to me that Endnotes place 
> > themselves at the End of a document; this prevents an alphabetical Index 
> > being placed there, which is the usual location for it.  Perhaps this 
> > should be considered for alteration in a forthcoming revision of Writer.
> >
> Hi, Rory,
> 
> Would a "fake" master doc (only one sub-document) be a quick way around 
> this problem? The endnotes should stay with the chapter, and the index, 
> specified in the master, should come last. (I don't use these features, 
> so I can't say for sure.)

My documents are simple book text with no internal funnies or illustrations, so 
I've never used Master Documents.  Having seen (on Forum) many reports of 
trouble with Master Documents, I'd hesitate to advise someone with a nearly 
finished text to transfer to a Master Document structure - it could turn to a 
can of worms!
-- 
Rory O'Farrell 

Re: Draft: Guidelines for redistributing (an original) Apache OpenOffice with 3rd party bundles (e.g. books or template packages)

[Rob Weir]

On Sun, Dec 30, 2012 at 6:14 AM, Peter Junge  wrote:
> Hi,
>
> from time to time there are requests to bundle OpenOffice with 3rd party
> products. A typical case is that a publishing house wants to release a
> commercial box in which they bundle an original version of Apache OpenOffice
> with a handbook (either printed or electronic) and some goodies like a pack
> of templates. As I'm expecting such cases will pop-up frequently (mostly at
> private@, hence they're not too visible here), it would be good to have some
> guidelines in place. I have drafted some, please review and comment. The
> result is intended to be submitted as a proposal here and should go on our
> website later.
>

You need to review this with Shane as well.  Remember, the PMC does
not control the OpenOffice trademarks.  Apache does, and Shane has
delegated authority in these matters.


> Happy New Year
> Peter
>
> -
>
> === Guidelines for redistributing (an original) Apache OpenOffice with 3rd
> party bundles ===
>
> 1) You must solely use an unmodified binary version of Apache OpenOffice
> that can be downloaded by anyone from
> http://www.openoffice.org/download/index.html. If you build your own product
> from the Apache OpenOffice sources, then you must give your product a
> different name that must not be confused with Apache OpenOffice. Under
> certain circumstances, you may then use 'Powered by Apache OpenOffice'. For
> details, please refer:
> http://www.apache.org/foundation/marks/faq/#poweredby
>

I think this is mixing up two different things:

1) Building exactly AOO from the source, with no additional material
bundled.  This would be a port, like the BSD or Solaris or OS/2 port.
Are you saying that these  may not be called "Apache OpenOffice"?

2) Distributing AOO bundled with other stuff.  In that case the AOO
portion may still be called "Apache OpenOffice", of course. But the
question is what do you call the bundle as a whole?

IMHO, the "powered by" name was not intended for bundling.  It was
intended for embedding, when an Apache program was used as a component
behind the scenes for some processing, e.g., run on the server to
generate PDF's, etc.  But to have a bundle of AOO + templates or other
content and call it "Foo Office, Powered by Apache OpenOffice" is a
big fail, since the product splash screen, the title bar and the about
box, not to mention the installer, will still all say "Apache
OpenOffice".


> 2) You must always use the proper name 'Apache OpenOffice x[.y[.z]]' (e.g.
> 3.4.1) for our product. IMPORTANT: Do NOT use 'Apache Open Office' or
> 'Apache OpenOffice.org' or 'OpenOffice' or 'Open Office' or 'OpenOffice.org'
> etc.
>

???  We just said in #2 that "you must give your product a different
name that must not be confused with Apache OpenOffice".  And now you
are saying something (what?) must be referred to as the proper name
"Apache OpenOffice 3.4.1".

This doesn't work well for another reason:  there is nothing that
requires that someone build a bundle from exactly a released version
of AOO.  It might not be exactly 3.4.1.  It might be pre 4.0, or 3.4.1
+ fixes.  How exactly it is named may cause or prevent confusing for
support and bug tracking,


> 3) Do not use any additions to 'Apache OpenOffice x.y.z' with the title of
> your bundle that imply that you are shipping a product which is superior to
> Apache OpenOffice, e.g. you must not use a title like 'Apache OpenOffice
> 3.4.1 Professional'. You may rather use the title 'Apache OpenOffice 3.4.1'
> with a subtitle like '{YOUR_BRAND} Professional Pack' because you have added
> value to an original Apache OpenOffice.
>

OK.

> 4) If you want to use the Apache OpenOffice logo on your bundle, you must
> solely use the original, unmodified Apache OpenOffice logo:
> https://svn.apache.org/repos/asf/openoffice/ooo-site/trunk/content/images/AOO_logos/svg/OOo_Website_v2_copy.svg
>

I would not favor giving any blanket permission to use the primary
logo.  It should be used rarely, only with explicit permission, and on
a case-by-case basis.  If the volume of requests is so high that it is
burdensome to review them all then we should make a special logo just
for just bundles. But don't give away the crown jewels without review.
 For example compare the vendors who may use the "Intel Inside" logo
versus who is permitted to use the "Intel" logo.  You make a special
logo for bundling.

> 5) You must attribute the Apache Software Foundation and it's trademarks
> with all components of your bundle (e.g. Cover, Box, printed Book,
> electronic book, CD/DVD etc.). A proper attribution is:
> ---
> "Apache",[ the “Apache logo”,] "Apache OpenOffice", "OpenOffice" and the
> “Apache OpenOffice logo” are trademarks of the Apache Software Foundation
> (http://www.apache.org)
> ---
> For the detailed Apache Trademark Policy, please refer:
> http://www.apache.org/foundation/marks/
>

> 6) You must make clear with all components of your bundle (e.g

Re: Windows 8 compatibility

[Rob Weir]

On Sat, Dec 29, 2012 at 7:59 PM, F C. Costero  wrote:
> There is a steady stream of questions on the Google Questions list about
> AOO compatibility with Windows 8. Some mention a problem with installation
> and others merely ask if AOO will work on that OS. No details of the
> installation problems have been provided, so I have no reason to believe
> there is a technical problem. Also, I haven't seen much traffic on the en
> or es forums on this issue. However, it seems the download pages could be
> clearer about compatibility. This one:
> http://www.openoffice.org/dev_docs/source/sys_reqs_aoo34.html
> doesn't mention Windows 8 at all. Is there any reason not to include
> Windows 8 on that page?


Windows 8 was not officially released yet when AOO 3.4.1 was released.
  But we tested with the preview version of Windows 8 and AOO 3.4.1
appeared to work well.

So the question might be:  what level of testing do we require before
listing Windows 8 as "supported"?

-Rob

> Best regards,
> Francis

Re: 30 million downloads, year end blog post

[Roberto Galoppini]

On Fri, Dec 28, 2012 at 8:50 PM, Donald Harbison  wrote:
> On Fri, Dec 28, 2012 at 10:03 AM, Rob Weir  wrote:
>
>> Just noticed that we hit the 30 million download mark for AOO 3.4 on
>> December 22nd.
>>
>> That is a nice, round number.  Maybe we should do a year end blog
>> post, summarizing our achievements in 2012?
>>
>> Any ideas for content?
>>
>
> A nice timeline of achievements is always good, plus a simple line chart
> showing community growth and vitality.
>
> And, most important, forward looking content describing our goals for 2013.

Along this line, here what we plan to deliver for Extensions and
Templates sites by the end of February:

1) Platform and Content Migration to Drupal 7. The two sites, now on
Drupal 5 (unsupported) and Drupal 6, will be brought to the same
platform. Common code will work on both sites without need to be
adapted. This will bring improvements in performance, user experience
and multilingual support. All users, passwords (if applicable) and
content will be preserved during conversion.

2) Technical improvements. Automatic management of updates will be
available on Extensions, to enable update notifications in OpenOffice.
The site will export RSS feeds with new content.

During the process we'll keep providing users support, including
possible support to users who need to understand configuration
changes.

Also by the end of April we plan to work on the following items.

3) Search improvements. Search will be switched to an Apache Solr
backend; this allows much faster search, autocomplete of search terms,
"Did you mean" suggestions and "Saved searches" for each registered
user.

4) Web 2.0 services. The sites will support RSS feeds to export
specific searches (latest dictionaries, templates matching
"curriculum") to other sites. New content will automatically be posted
on dedicated Twitter channels. It will be possible to share on
Facebook/Twitter each extension/template and to rate the content with
the familiar 5-star widget.

5) Branding possibilities, replicated repositories. The sites can
display different content and branding if called with different domain
names (e.g., show only open source extensions when called as
open.extensions.openoffice.org). The sites can also be easily
replicated and reinstalled with full functionality (e.g., for a
company-wide internal repository of extensions or templates).

Let me know if you need more information.

Roberto

> I can help with this if you like. Will be back online later this afternoon.
>
>
>> 3.4.0 and 3.4.1 releases, graduation, ApacheCon EU.
>>
>> Anything else we could highlight?
>>
>> -Rob
>>

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Re: Test for unsubscribe link

[Rob Weir]

On Sun, Dec 30, 2012 at 4:38 AM, Peter Junge  wrote:
> On 12/30/2012 4:37 PM, Issac Goldstand wrote:
>>
>> It's in the headers.  All apache.org lists are like that.
>
>
> Yes, I noticed that, but with OpenOffice we need to consider that it's an
> end user software, so we have typical end users subscribed to our mailing
> list, especially with users@. These guys need to find the information to
> unsubscribe easily.
>

Right.  So that is why we had the unsubscribe link added for the users
list.  You should see it there.

-Rob

> Peter
>
>
>>
>> On 29/12/2012 16:03, Andrea Pescetti wrote:
>>>
>>> Peter Junge wrote:

 There's indeed no unsubscribe link coming with my email. Does anyone
 know if this is intended or is it a bug?
>>>
>>>
>>> I can't find any older messages to ooo-dev that include an unsubscribe
>>> link, or a footer in general. Configuring a footer is something that,
>>> as far as I know, only Infra can do, and you can find an example at
>>> https://issues.apache.org/jira/browse/INFRA-4512
>>>
>>> I would find it useful to have at least the "basic" footer
>>> (unsubscribe+help) added to all our international public lists listed
>>> at http://openoffice.apache.org/mailing-lists.html unless they already
>>> have one.
>>>
>>> Regards,
>>>   Andrea.
>>
>>
>

Re: Incompatible changes in AOO 4.0 ?

[Pedro Giffuni]

Hi Regina;


- Messaggio originale -
> Da: Regina Henschel 

> 
> A
> Implementation of FDIST as defined in ODF1.2
> 
> The function FDIST (part 2, 6.18.22) calculates the left tail (integral from 
> 0 
> to x). The function LEGACY.FDIST (part 2, 6.18.23) calculates the right tail 
> (integral from x to infinity). The current implemention of FDIST in AOO is 
> actually “LEGACY.FDIST”. The function FDIST in documents written with OOo2.x 
> are 
> different from the function FDIST, which has to be implemented. I do not 
> speak 
> of the UI names, but of the names in the file.
>

This sounds like FDIST = 1 - LEGACY.FDIST

It should be easy to "fix" and I think it should be done before 4.x.

BTW, I am considering doing something drastic there, like replacing all the 
probablilty
distributions with with boost implementations. Would there be any good reason to
avoid such approach?

Pedro.

Re: Incompatible changes in AOO 4.0 ?

[Rob Weir]

On Sun, Dec 30, 2012 at 1:19 PM, Pedro Giffuni  wrote:
> Hi Regina;
>
>
> - Messaggio originale -
>> Da: Regina Henschel
>
>>
>> A
>> Implementation of FDIST as defined in ODF1.2
>>
>> The function FDIST (part 2, 6.18.22) calculates the left tail (integral from >> 0
>> to x). The function LEGACY.FDIST (part 2, 6.18.23) calculates the right tail
>> (integral from x to infinity). The current implemention of FDIST in AOO is
>> actually “LEGACY.FDIST”. The function FDIST in documents written with OOo2.x 
>> are
>> different from the function FDIST, which has to be implemented. I do not 
>> speak
>> of the UI names, but of the names in the file.
>>
>
> This sounds like FDIST = 1 - LEGACY.FDIST
>
> It should be easy to "fix" and I think it should be done before 4.x.
>
> BTW, I am considering doing something drastic there, like replacing all the 
> probablilty
> distributions with with boost implementations. Would there be any good reason 
> to
> avoid such approach?
>

What is the advantage of changing?

Risk of any change is introducing a bug.  From a user's perspective
any difference in calculation, even if "correct" is something that may
cause them to halt their work until they understand why their complex
calculation gives an answer that is 0.1% different than AOO 3.4.1.

So we need both accuracy and release-to-release consistency.  Me may
improve accuracy and in the process yield results that differ from
earlier versions, but this needs to be tracked and communicated to
users carefully, so they understand what happened to their
spreadsheets.  I don't think we want "improvements" to be a surprise
for the user, especially since at that point bugs and improvements are
indistinguishable to casual examination.

If we don't have a solid test suite to determine whether our
calculations are correct or even detect if our calculations differ
from release to release then I'm not really in favor of changing the
code.  But if we wanted to do a rigorous test of OpenOffice, per the
standard, and fix any bugs or inaccuracies that the test suite
reveals, then I think we end up with a stronger product, and one where
we can safely optimize the routines, knowing that the test cases "have
our back".

-Rob


> Pedro.

Re: 30 million downloads, year end blog post

[Rob Weir]

On Fri, Dec 28, 2012 at 12:00 PM, janI  wrote:
> @Rob:
>
> google analytics was "lost in translation" on wiki, it should be back now.
>
> If you goto wiki.opensource.org, and edit page source, you should see the
> link to google_analytics.
>
> Sorry for mssing that feature,
>
> Can you please check during the next couple of days that it works again.
>

Just took another look.  GA is not showing up in the page source.

-Rob


> thx
> jan I.
>
> On 28 December 2012 17:40, Regina Henschel  wrote:
>
>> Hi Rob,
>>
>> Rob Weir schrieb:
>>
>>  Just noticed that we hit the 30 million download mark for AOO 3.4 on
>>> December 22nd.
>>>
>>> That is a nice, round number.  Maybe we should do a year end blog
>>> post, summarizing our achievements in 2012?
>>>
>>> Any ideas for content?
>>>
>>> 3.4.0 and 3.4.1 releases, graduation, ApacheCon EU.
>>>
>>> Anything else we could highlight?
>>>
>>
>> If there will be no other blog post till February, you can mention our
>> stand and our devroom on FOSDEM.
>>
>> Kind regards
>> Regina
>>

Re: Incompatible changes in AOO 4.0 ?

[Pedro Giffuni]

- Messaggio originale -
> Da: Rob Weir 
...
>> 
>>  BTW, I am considering doing something drastic there, like replacing all the 
> probability
>>  distributions with with boost implementations. Would there be any good 
> reason to
>>  avoid such approach?
>> 
> 
> What is the advantage of changing?
> 

Quality: the precision and performance in the boost implementations
is notable. Most of our older implementations are also unmaintained. If
you look at the Gamma implementation, for example, you will notice a
comment that says it is based on the boost implementation. We surely
haven't kept up with the bug fixes or improvements they may have made
since then.

The boost implementations also have the option of specifying math policy,
which is something our current implementations lack.

Quite honestly, I was hesitant to introduce boost stuff in Calc but we
already depend on it for other things so it comes for free and the code 
is admittedly very good (with only some small issues in their PRNG).

> Risk of any change is introducing a bug.  From a user's perspective
> any difference in calculation, even if "correct" is something that may
> cause them to halt their work until they understand why their complex
> calculation gives an answer that is 0.1% different than AOO 3.4.1.
> 

0.1% is a huge number: If the new functions produce 0.1 % more correct

results then I would say it's a bugfix and bug fixes are GREAT.

I have to say that some of the current math functions are in poor shape,
hopefully not 0.1% wrong but still pretty shameful.

We have to verify each and every function we replace but I don't think the
idea is to produce a crappy Spreadsheet that lies, and producing
inaccuracies in cases where we can do much better is pretty much lying.

> So we need both accuracy and release-to-release consistency.  Me may
> improve accuracy and in the process yield results that differ from
> earlier versions, but this needs to be tracked and communicated to
> users carefully, so they understand what happened to their
> spreadsheets.  I don't think we want "improvements" to be a 
> surprise
> for the user, especially since at that point bugs and improvements are
> indistinguishable to casual examination.
> 

Of course, there are "Release notes" for that: there are no surprises
here. Major release numbers bumps are useful precisely to indicate

such changes.

I would also think we will want to keep the legacy implementations
available in a scaddin. The beauty of opensource is that anyone is free
to lend a hand and do just that.

> If we don't have a solid test suite to determine whether our
> calculations are correct or even detect if our calculations differ
> from release to release then I'm not really in favor of changing the
> code.  But if we wanted to do a rigorous test of OpenOffice, per the
> standard, and fix any bugs or inaccuracies that the test suite
> reveals, then I think we end up with a stronger product, and one where
> we can safely optimize the routines, knowing that the test cases "have
> our back".
> 

Please feel free to contribute a spreadsheet that calculates the edge
cases. Any contribution of that kind is welcome, and that's why this list
exists.

We do have a serious problem in the current Calc: we are depending on
system libraries for some calculations. This has the disadvantage that the
results will differ if you do your calculation on Windows or in UNIX with
none of them being too good in accuracy. Under it's current shape I
wouldn't recommend a tool like calc for use in serious scientific use.

For the record, some of the math libraries used in some libc implementations
are derived from Netlib's Cephes and even though modern standards require
them, they have been rejected for inclusion in FreeBSD due to their low
quality.

I am pretty sure I know what I am doing here. I have a patch in my box to fix
some of the lower hanging fruit in Calc. You will probably not see any of it
this year, but it will be coming through bugzilla so that you have time to help
review the changes with real code :)..

Pedro.

Re: Incompatible changes in AOO 4.0 ?

[Andrew Pitonyak]

Improved accuracy its usually a good thing. I have considered that boost was a 
good choice so that our will not be system dependent.

in other words, i think it is a good idea.

Sent from my Samsung Epic™ 4G

Pedro Giffuni  wrote:



- Messaggio originale -
> Da: Rob Weir 
...
>> 
>>  BTW, I am considering doing something drastic there, like replacing all the 
> probability
>>  distributions with with boost implementations. Would there be any good 
> reason to
>>  avoid such approach?
>> 
> 
> What is the advantage of changing?
> 

Quality: the precision and performance in the boost implementations
is notable. Most of our older implementations are also unmaintained. If
you look at the Gamma implementation, for example, you will notice a
comment that says it is based on the boost implementation. We surely
haven't kept up with the bug fixes or improvements they may have made
since then.

The boost implementations also have the option of specifying math policy,
which is something our current implementations lack.

Quite honestly, I was hesitant to introduce boost stuff in Calc but we
already depend on it for other things so it comes for free and the code 
is admittedly very good (with only some small issues in their PRNG).

> Risk of any change is introducing a bug.  From a user's perspective
> any difference in calculation, even if "correct" is something that may
> cause them to halt their work until they understand why their complex
> calculation gives an answer that is 0.1% different than AOO 3.4.1.
> 

0.1% is a huge number: If the new functions produce 0.1 % more correct

results then I would say it's a bugfix and bug fixes are GREAT.

I have to say that some of the current math functions are in poor shape,
hopefully not 0.1% wrong but still pretty shameful.

We have to verify each and every function we replace but I don't think the
idea is to produce a crappy Spreadsheet that lies, and producing
inaccuracies in cases where we can do much better is pretty much lying.

> So we need both accuracy and release-to-release consistency.  Me may
> improve accuracy and in the process yield results that differ from
> earlier versions, but this needs to be tracked and communicated to
> users carefully, so they understand what happened to their
> spreadsheets.  I don't think we want "improvements" to be a 
> surprise
> for the user, especially since at that point bugs and improvements are
> indistinguishable to casual examination.
> 

Of course, there are "Release notes" for that: there are no surprises
here. Major release numbers bumps are useful precisely to indicate

such changes.

I would also think we will want to keep the legacy implementations
available in a scaddin. The beauty of opensource is that anyone is free
to lend a hand and do just that.

> If we don't have a solid test suite to determine whether our
> calculations are correct or even detect if our calculations differ
> from release to release then I'm not really in favor of changing the
> code.  But if we wanted to do a rigorous test of OpenOffice, per the
> standard, and fix any bugs or inaccuracies that the test suite
> reveals, then I think we end up with a stronger product, and one where
> we can safely optimize the routines, knowing that the test cases "have
> our back".
> 

Please feel free to contribute a spreadsheet that calculates the edge
cases. Any contribution of that kind is welcome, and that's why this list
exists.

We do have a serious problem in the current Calc: we are depending on
system libraries for some calculations. This has the disadvantage that the
results will differ if you do your calculation on Windows or in UNIX with
none of them being too good in accuracy. Under it's current shape I
wouldn't recommend a tool like calc for use in serious scientific use.

For the record, some of the math libraries used in some libc implementations
are derived from Netlib's Cephes and even though modern standards require
them, they have been rejected for inclusion in FreeBSD due to their low
quality.

I am pretty sure I know what I am doing here. I have a patch in my box to fix
some of the lower hanging fruit in Calc. You will probably not see any of it
this year, but it will be coming through bugzilla so that you have time to help
review the changes with real code :)..

Pedro.

Re: Incompatible changes in AOO 4.0 ?

[Rob Weir]

On Sun, Dec 30, 2012 at 2:27 PM, Pedro Giffuni  wrote:
>
>
> - Messaggio originale -
>> Da: Rob Weir
> ...
>>>
>>>  BTW, I am considering doing something drastic there, like replacing all the
>> probability
>>>  distributions with with boost implementations. Would there be any good
>> reason to
>>>  avoid such approach?
>>>
>>
>> What is the advantage of changing?
>>
>
> Quality: the precision and performance in the boost implementations
> is notable. Most of our older implementations are also unmaintained. If
> you look at the Gamma implementation, for example, you will notice a
> comment that says it is based on the boost implementation. We surely
> haven't kept up with the bug fixes or improvements they may have made
> since then.
>
> The boost implementations also have the option of specifying math policy,
> which is something our current implementations lack.
>
> Quite honestly, I was hesitant to introduce boost stuff in Calc but we
> already depend on it for other things so it comes for free and the code
> is admittedly very good (with only some small issues in their PRNG).
>
>> Risk of any change is introducing a bug.  From a user's perspective
>> any difference in calculation, even if "correct" is something that may
>> cause them to halt their work until they understand why their complex
>> calculation gives an answer that is 0.1% different than AOO 3.4.1.
>>
>
> 0.1% is a huge number: If the new functions produce 0.1 % more correct
>
> results then I would say it's a bugfix and bug fixes are GREAT.
>
> I have to say that some of the current math functions are in poor shape,
> hopefully not 0.1% wrong but still pretty shameful.
>
> We have to verify each and every function we replace but I don't think the
> idea is to produce a crappy Spreadsheet that lies, and producing
> inaccuracies in cases where we can do much better is pretty much lying.
>
>> So we need both accuracy and release-to-release consistency.  Me may
>> improve accuracy and in the process yield results that differ from
>> earlier versions, but this needs to be tracked and communicated to
>> users carefully, so they understand what happened to their
>> spreadsheets.  I don't think we want "improvements" to be a
>> surprise
>> for the user, especially since at that point bugs and improvements are
>> indistinguishable to casual examination.
>>
>
> Of course, there are "Release notes" for that: there are no surprises
> here. Major release numbers bumps are useful precisely to indicate
>
> such changes.
>
> I would also think we will want to keep the legacy implementations
> available in a scaddin. The beauty of opensource is that anyone is free
> to lend a hand and do just that.
>
>> If we don't have a solid test suite to determine whether our
>> calculations are correct or even detect if our calculations differ
>> from release to release then I'm not really in favor of changing the
>> code.  But if we wanted to do a rigorous test of OpenOffice, per the
>> standard, and fix any bugs or inaccuracies that the test suite
>> reveals, then I think we end up with a stronger product, and one where
>> we can safely optimize the routines, knowing that the test cases "have
>> our back".
>>
>
> Please feel free to contribute a spreadsheet that calculates the edge
> cases. Any contribution of that kind is welcome, and that's why this list
> exists.
>

Well, what does boost use for its own testing?  They must do some sort
of testing?   Is there something we can easily convert into a
spreadsheet?  That would help in two ways. since we could test the
existing implementation against the same test cases, to see if there
actually are any issues.   I assume that would be good to know.

> We do have a serious problem in the current Calc: we are depending on
> system libraries for some calculations. This has the disadvantage that the
> results will differ if you do your calculation on Windows or in UNIX with
> none of them being too good in accuracy. Under it's current shape I
> wouldn't recommend a tool like calc for use in serious scientific use.
>
> For the record, some of the math libraries used in some libc implementations
> are derived from Netlib's Cephes and even though modern standards require
> them, they have been rejected for inclusion in FreeBSD due to their low
> quality.
>
> I am pretty sure I know what I am doing here. I have a patch in my box to fix

More bugs come from overconfidence than from a respectful humility and
realization that the work we do is critical for millions of users and
that we should do everything possible to ensure that our code is
tested by more than just our own personal feelings of satisfaction.
IMHO.

> some of the lower hanging fruit in Calc. You will probably not see any of it
> this year, but it will be coming through bugzilla so that you have time to 
> help
> review the changes with real code :)..
>
> Pedro.
>

Re: Incompatible changes in AOO 4.0 ?

[Pedro Giffuni]

- Messaggio originale -
> Da: Rob Weir 
...
>> 
>>  Please feel free to contribute a spreadsheet that calculates the edge
>>  cases. Any contribution of that kind is welcome, and that's why this 
> list
>>  exists.
>> 
> 
> Well, what does boost use for its own testing?  They must do some sort
> of testing?   Is there something we can easily convert into a
> spreadsheet?  That would help in two ways. since we could test the
> existing implementation against the same test cases, to see if there
> actually are any issues.   I assume that would be good to know.
> 

This is not something one checks by grabbing someone else's testsuite,
it depends on the specific function you want to test.

Please check the excellent boost documentation:
http://www.boost.org/doc/libs/1_52_0/libs/math/doc/sf_and_dist/html/index.html


I don't think we have equivalent studies over our native versions :(.

> 
> More bugs come from overconfidence than from a respectful humility and
> realization that the work we do is critical for millions of users and
> that we should do everything possible to ensure that our code is
> tested by more than just our own personal feelings of satisfaction.
> IMHO.
>

Rather than overconfidence we are having respectful humility and realization
that our homebrew implementations don't really compare against the boost
versions.  


Of course that doesn't mean we should replace everything, but perhaps since
Regina knows this better she can make informed suggestions..

Pedro.

Re: Windows 8 compatibility

[Max Merbald]

I've been using Windows 8 since Oct 30, and I am also using Apache 
OpenOffice and I haven't had any problems so far. Of course I didn't 
have to install OpenOffice because I already had version 3.4.1 when I 
installed Win 8. So I can say there is no problem using AOO on Win 8 but 
I can't say anything about installing it.


Max


Am 30.12.2012 01:59, schrieb F C. Costero:

There is a steady stream of questions on the Google Questions list about
AOO compatibility with Windows 8. Some mention a problem with installation
and others merely ask if AOO will work on that OS. No details of the
installation problems have been provided, so I have no reason to believe
there is a technical problem. Also, I haven't seen much traffic on the en
or es forums on this issue. However, it seems the download pages could be
clearer about compatibility. This one:
http://www.openoffice.org/dev_docs/source/sys_reqs_aoo34.html
doesn't mention Windows 8 at all. Is there any reason not to include
Windows 8 on that page?
Best regards,
Francis

Re: Incompatible changes in AOO 4.0 ?

[Regina Henschel]

Hi Pedro,

Pedro Giffuni schrieb:

Hi Regina;


- Messaggio originale -

Da: Regina Henschel




A
Implementation of FDIST as defined in ODF1.2

The function FDIST (part 2, 6.18.22) calculates the left tail (integral from 0
to x). The function LEGACY.FDIST (part 2, 6.18.23) calculates the right tail
(integral from x to infinity). The current implemention of FDIST in AOO is
actually “LEGACY.FDIST”. The function FDIST in documents written with OOo2.x are
different from the function FDIST, which has to be implemented. I do not speak
of the UI names, but of the names in the file.



This sounds like FDIST = 1 - LEGACY.FDIST

It should be easy to "fix" and I think it should be done before 4.x.


No, that does not work. FDIST has a density and a cumulative kind, and 
LEGACY.FDIST is only cumulative and -more important- calculating the 
other tail of a distribution by "1-value" results in an accuracy disaster.


You have to calculate FDIST using the already existing Beta 
-distribution. I have still the solutions, which I have considered, on 
my PC, but the work is three years old. If you are interested, I can 
sent you the files. I would have to work my way into it again.


The real problem is not the implementation of FDIST itself, but the 
question whether we are now far away enough from ODF1.1 for an 
incompatible change.
Remember, that ODF1.1 has no namespace for functions. When an 
application only knowing ODF1.1 gets a file with function name "FDIST", 
it cannot detect, that it is not the old right-tail version, but the new 
left-tail version. The other way round an implementation in AOO has to 
detect, that in an old document "FDIST" might be the right-tail version. 
Current documents write the right-tail version already as LEGACY.FDIST 
although the UI name is still FDIST. I would have to examine in 
Bugzilla, when this has been introduced.


I have no solution for this problem.



BTW, I am considering doing something drastic there, like replacing all the 
probablilty
distributions with with boost implementations. Would there be any good reason to
avoid such approach?


Such solution had been considered already, but at that time the BOOST 
version, which was used in OOo, was too old. Now it might be possible, 
but I cannot judge it and do not know how to do it actually. It is 
surely nothing, that can be done till AOO4.0. You need someone to 
implement it, preferably in a branch, and at least one other person with 
knowledge in distributions to do QA. It should not be decided between 
holidays, when a lot of persons are on vacation.


Kind regards
Regina

Re: Incompatible changes in AOO 4.0 ?

[Pedro Giffuni]

Hi Regina;


- Messaggio originale -
> Da: Regina Henschel 
...
> 
> I have no solution for this problem.
> 

I see.. In theory I am rather busy but I find time to do two or three things at 
a time ;)
There is no need to hurry this type of things for 4.0.

>> 
>>  BTW, I am considering doing something drastic there, like replacing all the 
> probablilty
>>  distributions with with boost implementations. Would there be any good 
> reason to
>>  avoid such approach?
> 
> Such solution had been considered already, but at that time the BOOST 
> version, 
> which was used in OOo, was too old. Now it might be possible, but I cannot 
> judge 
> it and do not know how to do it actually. It is surely nothing, that can be 
> done 
> till AOO4.0. You need someone to implement it, preferably in a branch, and at 
> least one other person with knowledge in distributions to do QA. It should 
> not 
> be decided between holidays, when a lot of persons are on vacation.
> 

Sounds reasonable. I did some very basic stuff and it looks good so far, but 
TBH,
the difference between using the boost versions and the native versions is
basically unnoticeable (which is to be expected).

Pedro.

Re: Incompatible changes in AOO 4.0 ?

[Andrew Pitonyak]

If the change is made, a good first step is a spread sheet with test cases.

So you have a proposed list of functions that would be changed?

Would want too compare expected group actual and old to new.

Would want to devise test cases against both common and edge cases. 

Also curios about time impact, does it take more time or less.


Sent from my Samsung Epic™ 4G

Pedro Giffuni  wrote:

Hi Regina;


- Messaggio originale -
> Da: Regina Henschel 
...
> 
> I have no solution for this problem.
> 

I see.. In theory I am rather busy but I find time to do two or three things at 
a time ;)
There is no need to hurry this type of things for 4.0.

>> 
>>  BTW, I am considering doing something drastic there, like replacing all the 
> probablilty
>>  distributions with with boost implementations. Would there be any good 
> reason to
>>  avoid such approach?
> 
> Such solution had been considered already, but at that time the BOOST 
> version, 
> which was used in OOo, was too old. Now it might be possible, but I cannot 
> judge 
> it and do not know how to do it actually. It is surely nothing, that can be 
> done 
> till AOO4.0. You need someone to implement it, preferably in a branch, and at 
> least one other person with knowledge in distributions to do QA. It should 
> not 
> be decided between holidays, when a lot of persons are on vacation.
> 

Sounds reasonable. I did some very basic stuff and it looks good so far, but 
TBH,
the difference between using the boost versions and the native versions is
basically unnoticeable (which is to be expected).

Pedro.

Re: Incompatible changes in AOO 4.0 ?

[Pedro Giffuni]

Hi Andrew;


- Messaggio originale -
> Da: Andrew Pitonyak 

> 
> If the change is made, a good first step is a spread sheet with test cases.
> 
> So you have a proposed list of functions that would be changed?
> 

I did just a very small set of changes for asinh, acosh, atanh and a some
internal power functions .. just for testing.

Since there is interest in this I opened a Bugzilla issue with the patch:
https://issues.apache.org/ooo/show_bug.cgi?id=121561


There's also a spreadsheet with some basic tests.
> Would want to compare expected group actual and old to new.
> 
> Would want to devise test cases against both common and edge cases. 
> 
> Also curios about time impact, does it take more time or less.
>


The differences are insignificant comparing FreeBSD amd64 (with boost)
vs a VM running Windows XP with Symphony, but I am sure someone
can come up with more creative tests :).

Perhaps someone not necessarily technically oriented, can create
a wiki page with a table of the functions in boost 1.48 that we may want.

Some stuff like GCD and LCM is simply more work than is worth it but
if there is something that we simply don't have already (perhaps some
weird stats distribution) , chances are good we can bring it in for 4.0.

Pedro.

Presentation for Apache Asia Roadshow 2012 Beijing is available (was: Presentation file under ALv2)

[Shenfeng Liu]

Peter,
  Thanks very much to consolidate the slides with Apache license!
  I added the link in the Events Calendar
wiki
.

- Shenfeng (Simon)


2012/12/29 Peter Junge 

> On 12/27/2012 4:10 PM, Ross Gardler wrote:
>
>> Yes Apache license is applicable to docs and presentations. If distributed
>> via the ASF then they should be Apache licensed.
>>
>
> OK, so it's the Apache License v2 that we have been choosing. We added a
> slide with IPR notices at page #2. The same information is available with
> the meta data. Anyone, please feel free to review:
> http://people.apache.org/~pj/**Apache_Asia_Road_Show_2012_**
> Beijing_OpenOffice_With_ALv2.**odp
>
> Best regards,
> Peter
>
>
>
>> Ross
>>
>> Sent from a mobile device, please excuse mistakes and brevity
>> On 27 Dec 2012 04:59, "Peter Junge"  wrote:
>>
>>  Hi,
>>>
>>> does anyone know if there's a common/best practice to put presentation
>>> files under ALv2 (or maybe another license like CC)? Is ALv2 applicable
>>> on
>>> presentations and other documents at all? If yes, how to issue the
>>> license
>>> with the presentation file? First page and/or last page and/or footer of
>>> each page and/or metadata?
>>>
>>> Concrete Situation: Liu Shengfeng, Liu Dali, Liu Tao and me have been
>>> presenting at the Apache Asia Roadshow 2012 and want to make our
>>> presentation file public with a proper license.
>>>
>>> Hope everyone had a nice Christmas and wishing a Happy New Year
>>> Peter
>>>
>>>
>>

Re: Windows 8 compatibility

[Joost Andrae]

Hi,



Windows 8 was not officially released yet when AOO 3.4.1 was released.
   But we tested with the preview version of Windows 8 and AOO 3.4.1
appeared to work well.

So the question might be:  what level of testing do we require before
listing Windows 8 as "supported"?



The question is: Do VCL or SAL support Win8's touch interface ? Are 
there any other changes in Win8 that need to be supported ? If AOO wants 
to fully support Win8 platforms is there a legal way to build and to 
distribute a Win8 ARM version without following Win8's (closed shop) 
business model ? Is it compatible to Apache's license ?


...just some ideas...

Joost