Re: Hello!

[Andrea Pescetti]

Ruth Cunningham wrote:

My name's Ruth Cunningham, from West London.
I'm currently studying at University, interested in Social Research
but looking to explore Marketing.


Welcome, Ruth! If you want to help with marketing you will find 
information at

http://incubator.apache.org/openofficeorg/orientation/intro-marketing.html
and please make sure to subscribe to the marketing mailing list: send an 
empty e-mail to marketing-subscr...@openoffice.apache.org and respond to 
the confirmation request you will receive.

Regards,
  Andrea.

Re: [RELEASE] AOO.next = AOO 4.0

[Jürgen Schmidt]

On 12/6/12 11:00 PM, Andrea Pescetti wrote:
> On 04/12/2012 Ariel Constenla-Haile wrote:
>> What was the outcome of this thread? Is trunk in 4.0 mode?
>> Andrea update to https://cwiki.apache.org/confluence/x/f8KoAQ
>> suggests so (I may have missed some mail telling so).
> 
> No formal mail was sent, but there was large consensus on 4.0, so we can
> assume the trunk to be in 4.0 mode. All recently integrated changes into
> http://svn.apache.org/viewvc/openoffice/trunk/ go in this direction too.
> 

that is my understanding as well, let us concentrate on AOO 4.0

Juergen

[QA] Two bugs very annoying for french users

[FR web forum]

Hello list,

Since AOO 3.4.0, two issues with Calc are poisoning for french
https://issues.apache.org/ooo/show_bug.cgi?id=119177
https://issues.apache.org/ooo/show_bug.cgi?id=120559
These bugs may be related.

Many people have been reported on the FR forum and the advice is to "install 
LibO".
Thanks to developers to have a look and fix it for next release.

Re: [RELEASE] Update 4.0 planning items

[TJ Frazier]

On 12/6/2012 23:11, Shenfeng Liu wrote:

Hi, all,
   I suggest we update the planning items in 4.0 wiki:
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning
   I just updated the status of each items and added some more according to
my reading of the mails.
   I hope every one can help to review the list and:

(1) input your name if you volunteer to any of the items (especially those
without owner now);
(2) for those in "Proposed" status, update the wiki or reply to this mail,
confirming if you still think you can/will deliver it in 4.0, or if you
prefer to move it to future releases, or think it is no longer important or
valid.
(3) add new items that you are working on or you plan to deliver in 4.0.

   Then by the end of next week, I propose to move out those with no
volunteer (I intent to move most of those items to 4.1 planning wiki
temporary), then update the rest according to the response from volunteers.
   Please tell me if any comments/suggestion. And very appreciate for the
update!
   Thanks!

- Shenfeng (Simon)

The "Encryption GUI" item has not attracted a sponsor. I added this per 
the resolution of a very long discussion in BZ [1]. Subsequently, Jürgen 
wrote an extension to set "SHA256" mode, and I wrote a macro[2] to 
toggle the settings; both are still available. (I have no idea whether 
any or many users have used them.)


[1] 

[2] 
(this page includes text suitable for release notes)

If somebody wants to pick up on this, and implement a GUI (probably in 
Tools > Options, possibly on the Save and Save As dialogs), that's 
wonderful. Lacking all fu for SVN and C++, I can't volunteer for this.


If we let the GUI slide, and keep the status quo, then I have a couple 
of suggestions:


1) I will try to enhance the macro to change the active settings. 
Currently, it changes the values in rm.xcu, which do not take effect 
until the suite is restarted (not very convenient, but much better than 
having to edit the parameter file by hand). I have failed at this before 
(the documentation has problems), but I will try again.


2) Add the macro to the Basic Tools library, possibly in its own module. 
I can supply a .txt or .bas file, or it can simply be scraped off the 
wiki page. This is the easiest way I know to distribute a macro whose 
lifetime should be that of the version; easy to add, easy to refer to in 
the notes, and easy for users to get at. If I can't update the macro by 
code-cutoff time, we can go with what we have.


/tj/

Re: [RELEASE] Update 4.0 planning items

[Ariel Constenla-Haile]

On Fri, Dec 07, 2012 at 08:55:23AM -0500, TJ Frazier wrote:
> The "Encryption GUI" item has not attracted a sponsor. I added this
> per the resolution of a very long discussion in BZ [1].  Subsequently,
> Jürgen wrote an extension to set "SHA256" mode, and I wrote a macro[2]
> to toggle the settings; both are still available.  (I have no idea
> whether any or many users have used them.)
> 
> [1] 
> 
> [2]  (this
> page includes text suitable for release notes)
> 
> If somebody wants to pick up on this, and implement a GUI (probably in
> Tools > Options, possibly on the Save and Save As dialogs), that's
> wonderful. Lacking all fu for SVN and C++, I can't volunteer for this.

the best way is to start a new thread asking for UX advice where to
include the option. IMHO the Save dialogs are a no-go, the average user
will have no idea what this means.

On the other hand, Tools > Options > Load/Save > General has almost no
space to add anything else, but may be a new "Encryption" options page
is an overhead...


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpKNUd3s4JkM.pgp
Description: PGP signature

Re: Gallery extension from Symphony ressources

[Ariel Constenla-Haile]

Hi Regina,

On Mon, Dec 03, 2012 at 05:59:15PM +0100, Regina Henschel wrote:
> Hi all,
> 
> Armin Le Grand schrieb:
> > Hi Kevin and Marcus,
> >
> >let's wait and see if Regina may know/find a place in the office where
> >this is needed.
> 
> I see that the folder htmlexpo is used in File > Wizards > Web Page..
> 
> But I do not see any of the selected pictures in the result of the
> Wizard. Does someone know, where these picture should appear in the
> result of the Wizard? Or has some function be removes from the
> wizard some time ago, without removing the selection?

The fixed text on the wizard step "5. Style" says "The icon set is used
for presentations in HTML format", so I guess one has to choose an ODP
in step "2. Documents" and "Export to file format" = HTML.

I couldn't make this work, I always get an error box "An error occurred
while copying media files to the temporary directory", the ODP file is
not even exported, I get an empty /content/ folder.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpC0YN70mzAT.pgp
Description: PGP signature

Google Communities

[Rob Weir]

Something new from Google:
http://googleblog.blogspot.com/2012/12/google-communities-and-photos.html

As you probably know we already have a Google+ Page:
https://plus.google.com/+openoffice

A Google+ Page is primarily a one-to-many broadcast tool, like a Blog
or a Twitter account or a Facebook page.  There is also opportunity
for users to respond back and comment on our posts, or share or
forward our posts, but it is centered on what we post.  These accounts
are our voice as project.

In addition to these accounts, there are more community-oriented
accounts.  For example, Facebook has a concept of a "Facebook Group".
This is more of a discussion forum, with members having an equal voice
on topics of discussion.  We have a Facebook Group for OpenOffice that
Raphael has been moderating:
https://www.facebook.com/groups/338330086179568/.

With the announcement of Google Communities, Google has created an
analog of Facebook Groups.  We now have the opportunity to have that
kind of discussion forum experience on Google+.

I've reserved a Google+ Community with the name "Apache OpenOffice.
We should decide what we want to do with it.

1) One view is that we should concentrate on a small number of social
networking platforms and require users to come to us if they want to
engage with us.

2) Another view is that we should fully engage with every new platform
that comes along and be liberal in the platforms we engage with.

3) Another view is that we should preserve the option of participating
in all platforms, experiment with new ones, see what works, and
concentrate on the platforms that are most effective.

Personally, I'm an advocate of approach #3.  We cannot predict what
"the next big thing" will be, so it is worth experimenting with new
approaches.

So if there are no objections, I'll continue preparing the Google+
Community for Apache OpenOffice and create an announcement.  I could
use help, of course.  So if anyone wants to be a co-moderator, send me
your Google ID.  It helps if you already have some experience with
Google+.

Regards,

-Rob

Problem with the installation

[S Vilcko]

Hello,

When I wanted to install your software Apache OpenOficce incubating
3.4.1.Win x86 install cs.exe
my software COMODO Defense+ warned me that

1/ your software is requesting unlimited access to my komputer (see
picture in enclosure)
2/ your software is not digitally signed (see picture in enclosure)

Questions:
1/ Why does your software regests unlimited access to my computer?
2/ Why is your software not digitally signed and shouldn’t be trusted?

Thank you for your quick answer.

Vilckos

Re: [Call-for-Review] Extension to XSmartTagRecognizer interface

[Jürgen Schmidt]

On 11/23/12 6:56 PM, Robert Barbey wrote:
> Here it is: https://issues.apache.org/ooo/show_bug.cgi?id=121391

Hi Robert,

I took the time and looked in the patch. And I talked with Oliver about
it and we have some questions/comments

1. the new method "commitTextMarkupRange" seems to be for convenience
only or from our pov obsolete.
Instead of calling the new method commitTextMarkupRange(.., xRange, ..)
the existing method commitTextMarkup(.., xRange.getStart(),
xRange.getEnd() - xRange.getStart(), ..) can be called.

2. Can you explain in more detail why you need the XTextRange object in
the recognize function instead of just of simply the text, start and end?
We assume you need it to identify your already prepared text ranges and
check if they are related to the current text, correct? You do a much
more complicate analysis of the text via the server and you use the
SmartTag API to visualize the results and provide the related actions.

Anyway the name "recognizeAll" seems to be not really appropriate. The
normal "recognize" method is called for text portions depending on their
locale. This make sense to use the break iterator. You have done this
already and simply want recognize or better commit the result only for
the whole text (paragraph).
"recognizeAllLocales" would be probably a better name.

But when you implement a SmartTag you have to implement both function
and you get called for both. That seems to be not optimal and I am
thinking if it would be better to

A. put the new method in a separate optional interface and check if the
this interface is implmented or not and make the call of this method
depending on the availability of this interface.

B. change the existing (not published) API and replace the first
argument "string" to "XTextRange". I have to double check the
implementation and my test SmartTag but it seems that aText contains
always the complete text of the paragraph.

But let us discuss it in more detail, I will do some real check and you
explain for what exactly you need the range object.

Juergen






> 
> Thanks again,
> Robert
> 
> 
> I just double-checked, I did attach a file (puh!) and it must have been 
> removed by mailing list policies.
> 
> But I will follow Oliver's suggestion and file a bug first.
> 
> Thanks for your help,
> Robert
> 
> 
> On 23.11.2012, at 18:12, "Jürgen Schmidt" 
> mailto:jogischm...@gmail.com>> wrote:
> 
> On 11/23/12 5:45 PM, Robert Barbey wrote:
> Hi everyone,
> 
> for a Writer extension, we're traversing a document using the Java text 
> iteration API. The text is extracted and sent to a server backend for 
> linguistic analysis. This server returns a report containing corrections for 
> the current document which the extension needs to map back into the document. 
> All of this is based on XTextRange objects.
> 
> In order to highlight these corrections within document, we are using smart 
> tags. But with the existing XSmartTagRecognizer interface it's not possible 
> to determine reliably the absolute position of  the text that is to be 
> processed in the recognize method of the interface. To be able to do that we 
> would need an XTextRange object as argument. This, of course, would require a 
> change of the XTextMarkup interface so that it also supports committing 
> markup for XTextRanges.
> 
> In the attached file, you find a patch that adds this functionality. It would 
> be really great if you could review these changes and provide feedback for 
> improvements or if you think that we have missed something essential. WE 
> think that this addition could be beneficial to other extensions as well.
> 
> Thank you very much and have a nice weekend.
> 
> Best,
> Robert
> 
> Hi Robert,
> 
> I am looking forward to see your patch ;-)
> 
> The good news is that XTextMarkup is an unpublished interface yet and I
> don't expect to many SmartTag extensions yet. We will see...
> 
> Normally API changes are not easy to make, especially with already
> published API's.
> 
> Juergen
> 
> 

Re: [RELEASE] Update 4.0 planning items

[Jürgen Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/7/12 3:18 PM, Ariel Constenla-Haile wrote:
> On Fri, Dec 07, 2012 at 08:55:23AM -0500, TJ Frazier wrote:
>> The "Encryption GUI" item has not attracted a sponsor. I added
>> this per the resolution of a very long discussion in BZ [1].
>> Subsequently, Jürgen wrote an extension to set "SHA256" mode, and
>> I wrote a macro[2] to toggle the settings; both are still
>> available.  (I have no idea whether any or many users have used
>> them.)
>> 
>> [1] 
>> 
>> [2] 
>> (this page includes text suitable for release notes)
>> 
>> If somebody wants to pick up on this, and implement a GUI
>> (probably in Tools > Options, possibly on the Save and Save As
>> dialogs), that's wonderful. Lacking all fu for SVN and C++, I
>> can't volunteer for this.
> 
> the best way is to start a new thread asking for UX advice where
> to include the option. IMHO the Save dialogs are a no-go, the
> average user will have no idea what this means.
> 
> On the other hand, Tools > Options > Load/Save > General has almost
> no space to add anything else, but may be a new "Encryption"
> options page is an overhead...
> 

Mmh, maybe directly over the "Size optimization ..." checkbox.

I have thought initially about Tools -> Options -> OpenOffice.org ->
Security. There should be enough place for a checkbox with some
explanation.

Juergen

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJQwhb+AAoJEM/u8xZRtf3oP2EP/jOzchb2sy8C+Pat1hygnzP8
CHreoVW2K7Zgmxs9WPsAuhz6NEH6dhmwg2kHQsh+rP/6FbkXtcKdVuUavKF8JqqW
SlqKIu52Od6c2DBznhX3yEjj2/qcUOEOGL303TEXnINIxOYc4Xr2jbInbsB6Weaq
+RoxTUvRLIrP9l6j0iXR7GLmM2CKokKH6fzPXYn2jAVsYSMh9oeT55xTgOjww72m
ZS6/6FZdAtsjTplqDGUqsDcAZXOVd+qhjBHLFxzFEAsE0gQzKglKKZJsszZ6EcIj
b4PgpHfIHrkvcuIHOe0O+aDrxd0lwuYBONFHb9hA4+4JHi+rBnLHDxHAUkbHljC1
IHNXxYJP+d8Sb7VDHuKilqxlefZtrTJAqbcIveY0sONPQBSm+8NluxN4p26ko+RZ
TYXJEOHe4Xvz6FvG4bLyD2A2JwxgVLf8kVk/sayM3/x+QD+X0RLEUDQa4EhWYGdi
CugUxj0jbIyvumvY2EIslxQetMGuykeRmDw62jvAu65XFaquKuPaIbDmP/gpFISx
d+3dYO43wUVnCfrEQY1b3dJijSQbgjsC6GTr6JVF+YxcjNfJOIAe3gjvZsJal63X
v4UJVwQpVDm/eLpyH+YT4M6wEPz0a1f9N+zgRcdXVIOEH0lrVckHmM3bUjeUTyjp
GEb0OnjoK5eCGCfvUNx7
=Q2xu
-END PGP SIGNATURE-

Re: [Call-for-Review] Extension to XSmartTagRecognizer interface

[Ariel Constenla-Haile]

On Fri, Dec 07, 2012 at 05:01:42PM +0100, Jürgen Schmidt wrote:
> B. change the existing (not published) API and replace the first
> argument "string" to "XTextRange".

Is it a good idea to use a text range? this will allow modification of
this text range, unless you make it read-only, if possible at all.
I guess that the current approach of using a string instad of the text
range has to do with the fact that there might more than one smart tag
precessing the same string. If you give the smart tag a text range, you
cannot relay on the extension good will not to manipulate it.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgph9VT6mumvU.pgp
Description: PGP signature

Re: [Call-for-Review] Extension to XSmartTagRecognizer interface

[Jürgen Schmidt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/7/12 5:21 PM, Ariel Constenla-Haile wrote:
> On Fri, Dec 07, 2012 at 05:01:42PM +0100, Jürgen Schmidt wrote:
>> B. change the existing (not published) API and replace the first 
>> argument "string" to "XTextRange".
> 
> Is it a good idea to use a text range? this will allow modification
> of this text range, unless you make it read-only, if possible at
> all. I guess that the current approach of using a string instad of
> the text range has to do with the fact that there might more than
> one smart tag precessing the same string. If you give the smart tag
> a text range, you cannot relay on the extension good will not to
> manipulate it.
> 

a good point, do you have another idea?

The point is that Robert has made the evaluation of the document
already, the recognition if you want, and will use the SmartTag API to
visualize the results and provide proper actions.

I assume he has a list of text ranges already and have to provide the
markups only and put it in the SmartTag context.

The idea is to reuse this concepts because you get a lot of features
for free, context menu, you can define your own action based on the
SmartTag type, ...

Juergen


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBCgAGBQJQwhrvAAoJEM/u8xZRtf3oGiwQAKNCX3H54+J1tCn0InkPbFCM
0qq2S4FTSxG6db7lnrYbdMHaLixyZntNnQbr88bfg6Bmt0yans4CWNp/GyPOfCmB
gYWMQWZCqEEHSuR04BploxBprSCduaqQQkbKEE8ecrNVArg6EcE/xbOUnxqYPoSr
XQIaxMkBdyJdr5zieO9MOKAzpcQ4khs6DuKRmUn2j6sW8O7aoWgYJ/cSUDSbkc2P
2ouXEc7XNcEqPN4+/vrYu4UTzewtUIBa4WhJ3Dd2uWrsThvWsIKIMSdGYX6zKG0M
ePVyRiwq5zoAirslnYOZIkQ74Ng9d/ZmxpjS8N+nCFEV0M65AH7ToNE3lTmkr0cT
QBPqrBLuTHYOJWcb08Yi8lvuy1YBhilvIIg0F97GfeQcW5dZ3NBSRV+lTKXDHwxs
2f68RPydES5BEDK+ZXNWnSwqXfAzb1+nS7PWXZh/ApDoItSIB1go9Rdm2ffLD+BB
1N5w9U/lVtW/5qCGoSPqKFtTiTSgQKJ5DFtaM/xUtl6AZNsDE8JKmkrqd9os96sq
p0t43ZvKOPS2EjzRaamKlmWouO/n475aTJZBDxWTx/luTWsTrpwCS4haCshgHwD7
+PTjZAIZAhfEDEhu9XGBuVRkq6dp4bvzzbcGBPzN6usx2DAnPvikdqDSNzsEyjN1
OyILJ4r60wRUoOAlbOZF
=Cge5
-END PGP SIGNATURE-

[UX] UI options for document encryption

[Ariel Constenla-Haile]

On Fri, Dec 07, 2012 at 05:19:11PM +0100, Jürgen Schmidt wrote:
> >> The "Encryption GUI" item has not attracted a sponsor. I added
> >> this per the resolution of a very long discussion in BZ [1].
> >> Subsequently, Jürgen wrote an extension to set "SHA256" mode, and
> >> I wrote a macro[2] to toggle the settings; both are still
> >> available.  (I have no idea whether any or many users have used
> >> them.)
> >> 
> >> [1] 
> >> 
> >> [2] 
> >> (this page includes text suitable for release notes)
> >> 
> >> If somebody wants to pick up on this, and implement a GUI
> >> (probably in Tools > Options, possibly on the Save and Save As
> >> dialogs), that's wonderful. Lacking all fu for SVN and C++, I
> >> can't volunteer for this.
> > 
> > the best way is to start a new thread asking for UX advice where
> > to include the option. IMHO the Save dialogs are a no-go, the
> > average user will have no idea what this means.
> > 
> > On the other hand, Tools > Options > Load/Save > General has almost
> > no space to add anything else, but may be a new "Encryption"
> > options page is an overhead...
> > 
> 
> Mmh, maybe directly over the "Size optimization ..." checkbox.
> 
> I have thought initially about Tools -> Options -> OpenOffice.org ->
> Security. There should be enough place for a checkbox with some
> explanation.

Changing the subject so that Kevin et al. can find it.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpfpRz6KbKgv.pgp
Description: PGP signature

[Review before commit] Error in main/sysui/desktop/debian/makefile.mk

[janI]

I have had a problem building sysui on ubuntu, it comes up with an error
that
directory $(MISC)$/$(@:b) had the wrong permission (needed 755 < x < 775
and got 757)

I traced the problem to the makefile.mk, please see the diff:

Index: makefile.mk
===
--- makefile.mk(revision 1413582)
+++ makefile.mk(working copy)
@@ -81,7 +81,7 @@
 -$(RM) $(@:d)$(@:f:s/_/ /:1)_*
 $(RM) -r $(MISC)$/$(@:b)
 dmake $(MISC)$/$(@:b)$/DEBIAN$/{control postinst postrm prerm}
-@chmod -R g-w $(MISC)$/$(@:b)
+@chmod -R o-w $(MISC)$/$(@:b)
 @chmod a+rx $(MISC)$/$(@:b)$/DEBIAN $(MISC)/$(@:b)/DEBIAN/post*
$(MISC)/$(@:b)/DEBIAN/pre*
 @chmod g-s $(MISC)/$(@:b)/DEBIAN
 @mkdir -p $(PKGDIR)


Can somebody please verify my change, before I commit it ?

thanks in advance.
Jan I.

Re: [Call-for-Review] Extension to XSmartTagRecognizer interface

[Ariel Constenla-Haile]

On Fri, Dec 07, 2012 at 05:35:59PM +0100, Jürgen Schmidt wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 12/7/12 5:21 PM, Ariel Constenla-Haile wrote:
> > On Fri, Dec 07, 2012 at 05:01:42PM +0100, Jürgen Schmidt wrote:
> >> B. change the existing (not published) API and replace the first 
> >> argument "string" to "XTextRange".
> > 
> > Is it a good idea to use a text range? this will allow modification
> > of this text range, unless you make it read-only, if possible at
> > all. I guess that the current approach of using a string instad of
> > the text range has to do with the fact that there might more than
> > one smart tag precessing the same string. If you give the smart tag
> > a text range, you cannot relay on the extension good will not to
> > manipulate it.
> > 
> 
> a good point, do you have another idea?

mmm no. It just looked dangerous to give a text range in this case,
unless it's read-only.


> The point is that Robert has made the evaluation of the document
> already, the recognition if you want, and will use the SmartTag API to
> visualize the results and provide proper actions.

From the original post, it seems he is misusing the smart tag api:

"for a Writer extension, we're traversing a document using the Java text
iteration API. The text is extracted and sent to a server backend for
linguistic analysis. This server returns a report containing corrections
for the current document which the extension needs to map back into the
document. All of this is based on XTextRange objects.

In order to highlight these corrections within document, we are using
smart tags."


It looks like he is implementing a grammar checker with the smart tag
API: see css::linguistic.Proofreader

"provides a proofreader (often known as grammar checker) for text 

An implementation of this service will receive text and has to
identify the sentence end and report all errors found.

An implementation of this service is not limited to grammar checking at
all. It might also check style, used terms etc.  Basically it can check
every aspect of a single sentence. Since the text provided is always the
complete paragraph it can also choose to analyze the context of the
sentence currently required to be checked. However error reports need to
be limited to the current sentence."

Note that also XProofreading::doProofreading gets a string, not a text
range. May be the design was based on the idea that a string is safer
than a text range for concurrent proof reading by different proof
readers, and safe modification are allowed only through XFlatParagraph
of the ProofreadingResult.


> I assume he has a list of text ranges already and have to provide the
> markups only and put it in the SmartTag context.

yes, I understood this too.

> The idea is to reuse this concepts because you get a lot of features
> for free, context menu, you can define your own action based on the
> SmartTag type, ...

Yes, but it look like the design was not to give access to the text
range, but a string; I tend to think the underlying reason was that
giving a text range is not safe. 


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpbud5wIIwJ9.pgp
Description: PGP signature

Re: [Proposal] Create new mailing list: d...@openoffice.apache.org

[Albino Biasutti Neto]

Hi

2012/12/3 Rob Weir :
> Moderators:  Please respond if you can volunteer as moderator.  We
> should aim for 2 or 3 geographically dispersed.

We have sereval volunteer as moderator. :-)

> I'll wait 72 hours, and if no objections we can ask Andrea to submit
> the form for the new list creation.

The period was completed, I believe positive.

-- 
Albino

RE: [UX] UI options for document encryption

[Dennis E. Hamilton]

Please see  in addressing 
security vs protection in the UX also.

 1. CHOICE OF ENCRYPTION ALGORITHM

It is important to appreciate that there is no recommendation about AES for the 
ODF 1.2 manifest:algorithm-name.  The only mandated algorithm for conformant 
ODF 1.2 documents, producers, and consumers is Blowfish CFB.  Other encryptions 
defined in XML Encryption 1.0 are allowed in conforming documents but there is 
no interoperability provision for them in ODF 1.2.

The choice for Save with Password should be simply whether to use ODF 
1.0/1.1/1.2 Blowfish or (for ODF 1.2 only) AES-256.  

 2. HASHING THE START KEY

The only place where there is a meaningful SHA1 versus SHA256 determination for 
encryption is in the choice of manifest:start-key-generation-name.  This choice 
is independent of the encryption used.  It determines whether a 160-bit or a 
256-bit password hash is provided to the PBKDF2 with HMAC-SHA-1 for derivation 
of the actual encryption keys to be used.  That hash is a secret and there is 
some improvement in protecting the encryption when SHA256 is used.

For ODF 1.0/1.1/1.2 across the board, the common provision is with SHA1 as the 
default.  The use of SHA256 and provision of the optional 
manifest:start-key-generation-name attribute applies only to ODF 1.2 documents. 
 

IMPORTANT NOTE: When selecting 256 for ODF 1.2 encryptions (preferably only 
with the use of AES in ODF 1.2 documents), the URI 
 in the ODF 1.2 specification is 
INCORRECT.  It should be .  See
.

If it is thought meaningful to feed an SHA256 into PDBKDF2 instead of starting 
with an SHA1, by all means use it for ODF 1.2 documents when AES is the 
encryption algorithm.  There is probably no reason to make this an 
user-selectable option since ODF 1.2 consumers must accept either case and it 
is unclear what informed choice is to be expected of users.


 2. OTHER HASH CHOICES DON'T MATTER MUCH FOR ENCRYPTION

There should be no user selection concerning SHA1 versus SHA256 with respect to 
manifest:checksum.  The manifest:checksum and manifest:checksum-type provisions 
are neither security nor privacy related.  They are to assist in checking 
whether the decryption is succeeding.  The mandated cases for consumers only 
work on the first 1k bytes of the unencrypted file part and the choice between 
SHA1-1k and SHA256-1k is insignificant.  Only the SHA1-1k will work across all 
of ODF 1.0/1.1/1.2. SHA256-1k must be supported by ODF 1.2 consumers, so it is 
safe to use when producing an ODF 1.2-specific AES-256 encryption if desired.  
In this particular application of digital hashes, there is however no advantage 
of SHA256 over SHA1 and faster is better.  

Note: Either way, these checksum values disclose information about the 
*unencrypted* package file.  In the future, it is desirable to use encryption 
algorithms that allow manifest:checksum to be dropped while also verifying the 
integrity of the encryption/decryption.

 3. SELECTING HASHES FOR PROTECTION

Making a choice between SHA1 and SHA256 for *protections*, not encryptions, is 
meaningful only when a document is saved as ODF 1.2.  There is no choice when 
saving as ODF 1.0/1.1/1.2 for legacy compatibility.  The across-the-board 
default is SHA1.  Since protections are trivially defeated without any concern 
for the digital hash value of the protection key, the only reason for SHA256 is 
to make it slightly harder for someone to discover the password from the 
protection key.  

Since the protection key value is not a secret and it is easily extracted from 
the document, SHA256 versus (160-bit) SHA1 is not a big improvement.  Passwords 
used for protection keys are vulnerable to compromise and exploitation.  

See 
.


 - Dennis


-Original Message-
From: Ariel Constenla-Haile [mailto:arie...@apache.org] 
Sent: Friday, December 07, 2012 08:39
To: dev@openoffice.apache.org
Subject: [UX] UI options for document encryption

On Fri, Dec 07, 2012 at 05:19:11PM +0100, Jürgen Schmidt wrote:
> >> The "Encryption GUI" item has not attracted a sponsor. I added
> >> this per the resolution of a very long discussion in BZ [1].
> >> Subsequently, Jürgen wrote an extension to set "SHA256" mode, and
> >> I wrote a macro[2] to toggle the settings; both are still
> >> available.  (I have no idea whether any or many users have used
> >> them.)
> >> 
> >> [1] 
> >> 
> >> [2] 
> >> (this page includes text suitable for release notes)
> >> 
> >> If somebody wants to pick up on this, and implement a GUI
> >> (probably in Tools > Options, possibly on the 

Re: [UX] UI options for document encryption

[Ariel Constenla-Haile]

On Fri, Dec 07, 2012 at 10:26:02AM -0800, Dennis E. Hamilton wrote:
> Please see  in
> addressing security vs protection in the UX also.

[...]

very interesting, but this is another topic! Post another mail, find UX
advice and lazy consensus, and simply change

http://svn.apache.org/viewvc/openoffice/trunk/main/sfx2/source/dialog/dinfdlg.src?revision=1413471&view=markup#l754
Text [ en-US ] = "Security" ;

by

Text [ en-US ] = "Protection" ;

or any other suitable name :)


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgpwm4ql4NKHA.pgp
Description: PGP signature

Re: [Call-for-Review] Extension to XSmartTagRecognizer interface

[Juergen Schmidt]

Am Freitag, 7. Dezember 2012 um 18:09 schrieb Ariel Constenla-Haile:
> On Fri, Dec 07, 2012 at 05:35:59PM +0100, Jürgen Schmidt wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >  
> > On 12/7/12 5:21 PM, Ariel Constenla-Haile wrote:
> > > On Fri, Dec 07, 2012 at 05:01:42PM +0100, Jürgen Schmidt wrote:
> > > > B. change the existing (not published) API and replace the first  
> > > > argument "string" to "XTextRange".
> > > >  
> > >  
> > >  
> > > Is it a good idea to use a text range? this will allow modification
> > > of this text range, unless you make it read-only, if possible at
> > > all. I guess that the current approach of using a string instad of
> > > the text range has to do with the fact that there might more than
> > > one smart tag precessing the same string. If you give the smart tag
> > > a text range, you cannot relay on the extension good will not to
> > > manipulate it.
> > >  
> >  
> >  
> > a good point, do you have another idea?
>  
> mmm no. It just looked dangerous to give a text range in this case,
> unless it's read-only.
>  
>  
> > The point is that Robert has made the evaluation of the document
> > already, the recognition if you want, and will use the SmartTag API to
> > visualize the results and provide proper actions.
> >  
>  
>  
> From the original post, it seems he is misusing the smart tag api:
>  
> "for a Writer extension, we're traversing a document using the Java text
> iteration API. The text is extracted and sent to a server backend for
> linguistic analysis. This server returns a report containing corrections
> for the current document which the extension needs to map back into the
> document. All of this is based on XTextRange objects.
>  
> In order to highlight these corrections within document, we are using
> smart tags."
>  
>  
> It looks like he is implementing a grammar checker with the smart tag
> API: see css::linguistic.Proofreader
>  
Interesting, I simply hadn't this API on my radar. The question is how it is 
integrated in the UI when you provide an implementation.  

I believe Robert wants to have more control and of course wants to visualize 
the results with different colors in the document. Depending on the found item 
the user have different options via context menu or so.


> "provides a proofreader (often known as grammar checker) for text  
>  
> An implementation of this service will receive text and has to
> identify the sentence end and report all errors found.
>  
> An implementation of this service is not limited to grammar checking at
> all. It might also check style, used terms etc. Basically it can check
> every aspect of a single sentence. Since the text provided is always the
> complete paragraph it can also choose to analyze the context of the
> sentence currently required to be checked. However error reports need to
> be limited to the current sentence."
>  
> Note that also XProofreading::doProofreading gets a string, not a text
> range. May be the design was based on the idea that a string is safer
> than a text range for concurrent proof reading by different proof
> readers, and safe modification are allowed only through XFlatParagraph
> of the ProofreadingResult.
>  
>  
> > I assume he has a list of text ranges already and have to provide the
> > markups only and put it in the SmartTag context.
> >  
>  
>  
> yes, I understood this too.
>  
> > The idea is to reuse this concepts because you get a lot of features
> > for free, context menu, you can define your own action based on the
> > SmartTag type, ...
> >  
>  
>  
> Yes, but it look like the design was not to give access to the text
> range, but a string; I tend to think the underlying reason was that
> giving a text range is not safe.
>  
>  

I tend to agree, but in related Smarttags actions you will get the text range 
object anyway.

Juergen  
>  
>  
>  
> Regards
> --  
> Ariel Constenla-Haile
> La Plata, Argentina
>  
>  

Re: [Call-for-Review] Extension to XSmartTagRecognizer interface

[Ariel Constenla-Haile]

On Fri, Dec 07, 2012 at 07:56:12PM +0100, Juergen Schmidt wrote:
> > Yes, but it look like the design was not to give access to the text
> > range, but a string; I tend to think the underlying reason was that
> > giving a text range is not safe.
> >  
> >  
> 
> I tend to agree, but in related Smarttags actions you will get the
> text range object anyway.

But this is the intended design: concurrent smart tag processing, while
I assume that actions are not invoked concurrently: the user can select
only one menu item at the time with one action.

Concerning the proof reader, I don't have any at hand right now, but
IIRC the text is underlined with a dotted light blue line. I'll have to
try the LanguageTool to see what offers the context menu in this case.

Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


pgppfdUcbEw3Z.pgp
Description: PGP signature

Re: FAQ page (Re: IPAD)

[Keith N. McKenna]

Marcus (Ono) wrote:

Am 12/03/2012 11:11 PM, schrieb Rob Weir:

On Mon, Dec 3, 2012 at 4:49 PM, Marcus (OOo)
wrote:

Am 12/03/2012 09:19 PM, schrieb Rob Weir:


On Mon, Dec 3, 2012 at 2:54 PM, Keith N. McKenna
   wrote:


Rob Weir wrote:



On Sun, Dec 2, 2012 at 1:41 PM, Andrea Pescetti
wrote:



On 26/11/2012 Rob Weir wrote:




[Can I install Openoffice on my IPAD?] I nominate this for an FAQ.





I agree. But where is our FAQ page currently? Unfortunately,
there's an
"OpenOffice FAQ" easily reachable by search engines at
http://www.openoffice.org/faq.html and quite outdated (I don't know
whether
it's reachable from the home page, but it doesn't seem so).

Time to make a new FAQ available or update the old one and link
to it
from
the current site?



The current location of the FAQ is prominent in search results.  That
is valuable and worth preserving.

But the current FAQ contents are out of date.  They would need a lot
of work to update/correct them.

Although the FAQ's are presented in a way that is OK for the user,
the
static HTML source is structured in a way that will be painful to
maintain.   Getting a cleaner structure, for example using HTML
definition lists () would be easier and could be maintained via
the CMS web interface.

There is another set of FAQ's on the documentation wiki:
http://wiki.openoffice.org/wiki/Documentation/FAQ

These also appear to be unmaintained.  But I think the wiki version
would be easier to maintain.

So one possible resolution could be:

1) Take anything of use from the FAQ's at
http://www.openoffice.org/faq.html and copy them into new FAQ
items on
the wiki

2) Update the other FAQ's on the wiki

3) Add new items to the wiki FAQ (like the iPAD question)

4) Delete the old FAQ directory and replace with a single page that
directs the reader to the wiki FAQ's.


-Rob
-Rob


Regards,
 Andrea.





Rob;

I have been updating some of the FAQ's on the wiki site that were
tagged
as
needing help. I am more than willing to start a comprehensive
review and
clean-up of the User FAQ's on the documentation wiki if that is the
way
we
decide to go. The advantage is that the wiki is easier to maintain
and it
is
already categorized with a toc on the main page.



The other FAQ on the website is also categorized:
http://www.openoffice.org/faq.html

So whatever direction we start from we'll probably want to update and
consolidate.

In my personal opinion, mdtext on the website is a good solution here.
But my opinion takes a back seat when someone else actually volunteers
to do the work.  So if you prefer the wiki for this, then you have a
+1 from me.  I'd just recommend that you fold in anything good from
the existing website into the wiki, so we have can have a single FAQ
for the project.

Oh, actually we have a few other FAQs:

http://openoffice.apache.org/community-faqs.html

http://openoffice.apache.org/developer-faqs.html

http://openoffice.apache.org/pmc-faqs.html

Maybe a simplifying assumption could be:

1) We make the MWiki FAQ's be the user-facing FAQs about the product
and the project

2) We have the "internal" project-facing FAQ's on
openoffice.apache.org website, in their current mdtext format.



I also would like to see FAQs in the Wiki, for both parts. FAQs have the
attribute that they are never complete, need to be updated regularily
and
nearly anybody has something to add.



A website in mdtext is also easy to update and anyone can update it.
In some sense it is even easier than the wiki, since with the
anonymous mode an account registration is not even needed, unlike the
wiki,


I don't want to talk bad about the anonymous feature of the CMS.
However, it's not widely known how to use it but I think how to use and
change a wikipage is known better.


I'd also disagree with the belief that FAQs need to be frequently
changed.  They only need to be frequently *asked*.  For example, the
question about OpenOffice on iPad only needs to be answered once.  it
does not require frequent community enhancement.


Right, the better word is "extend", to add more content.


So, it should be the best if indeed anybody can do the update. That's
best
done within the Wiki. Mistakes can be corrected fast and bad changes
reverted easily.



The same is true of the website.

But let's be honest:  the FAQ's on the wiki have been neglected for a
long time.  Technological concerns are not the reason for this, since
they are already on the wiki.  Our problems are elsewhere.


It seems nobody wanted to do the work that is needed to keep it
up-to-date. ;-)


My preference for the mdtext is it is easier to style and looks
better.  Wikis are dog butt ugly, IMHO.  Fine for collaborating on
text, but for final publication they are ugly.  IMHO.


I doubt that we need pretty styling here. The users want information for
their question(s). It's not the primary goal to present it most pretty
and nice but competent and complete.

Furthermore, I support the standpoint of Keith: Re-new both FAQs in

RE: [UX] UI options for document encryption

[Dennis E. Hamilton]

I've given some of the technical considerations behind security and protection 
provisions for ODF 1.0/1.1/1.2 documents.  

I think for usability and UX, there are the following considerations:
 
 1. Choices offered to users are ones for which informed decisions can be made 
and there is clear guidance on the consequences of the choices.  

 2. The Choices concerning encryption of documents (those associated with "Save 
with Password") that are security and privacy related need to be clearly 
separated from those that are unrelated to both security and privacy (i.e., the 
various protection options).

 3. Since the use of message digests (SHA1, SHA256, and others that are allowed 
in ODF 1.2 documents) is employed in both protection and encryption, there 
should be no options about the message digests used.  The user choices should 
be with respect to the actual situations. 

SUGGESTIONS

 1. FOR ENCRYPTION

1.1 Currently on Save with Password (where folks know to find it already), 
there should be nothing but Save with Password dealt with on the dialog that 
comes up when a Save starts.

1.2 The choice should be between
 o ODF 1.0/1.0/1.2 Compatible (Blowfish)
 o ODF 1.2 Exclusive (AES256)

If the document is being saved as ODF 1.0/1.1, no choice should be offered. 
This is on the same panel that requests a password (though it might be 
preset).
There should be a way to confirm/cancel encryption separate from cancelling 
the save.

1.3  There can be a default radio-button preset when saving as ODF 1.2 
[extended].  
The default might be a configuration option for the ODF 1.2 case, but the 
choice should
still be offered.  (Forcing an user to make a major configuration decision 
for occasional
variations is undesirable.)

1.4 When enterprise configuration/customization is provided for, there 
might be ways to force
the choice in 1.2 as well as limiting Save As ... format choices.  I am 
assuming that is 
out-of-scope for this simple public user consideration.

1.5 It might be desirable to also have provisions for encryption in the 
Document Properties 
dialog, on its own tab there.  (Protections should be on a separate tab.)  
It can then be 
possible to set and to reset encryption, and a password could be elicited 
on setting, although
in that case it should still be cancellable at Save or Save As ... time.  
(See above.)
[The principle is to not take users down blind alleys.]

1.6 NO MATTER WHAT: The warnings about the document not being recoverable 
if the password is
lost or forgotten need to be prominent in all places where a choice is 
offered in the matter.


2. FOR PROTECTION

2.1 Protection dialogs already exist in various places.  Some 
whole-document protections are not in the same places.  There are UX 
considerations around when the protections are set and when they are 
implemented in the document that is produced.  Some can be set any time while 
editing the document and have immediate effect.  Some would prevent further 
editing so tend to not be set until the document is saved.  This requires more 
cases to be worked out.  

2.2 Generally, the choice is between ODF 1.0/1.1/1.2 compatibility and ODF 
1.2 exclusive functionality.  The difference in the SHA used is not a 
meaningful consequence for the user's informed choice.  

2.3 The current offering of document-level protections via an "Additional 
Options" button on the Save with Protection dialog has to move.  It's also done 
there and elsewhere in a confusing way.

2.4 NO MATTER WHAT: Protections must be disavowed as security and integrity 
features.  Users should be informed, in some manner, that protections are 
easily defeated and are mainly for safeguarding against accidental 
modifications.  In particular, users must be cautioned that the password used 
is not itself protected in a secure way and a valuable password should not be 
reused for this purpose.

 - Dennis


-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Friday, December 07, 2012 10:26
To: dev@openoffice.apache.org
Subject: RE: [UX] UI options for document encryption

Please see  in addressing 
security vs protection in the UX also.

 1. CHOICE OF ENCRYPTION ALGORITHM

It is important to appreciate that there is no recommendation about AES for the 
ODF 1.2 manifest:algorithm-name.  The only mandated algorithm for conformant 
ODF 1.2 documents, producers, and consumers is Blowfish CFB.  Other encryptions 
defined in XML Encryption 1.0 are allowed in conforming documents but there is 
no interoperability provision for them in ODF 1.2.

The choice for Save with Password should be simply whether to use ODF 
1.0/1.1/1.2 Blowfish or (for ODF 1.2 only) AES-256.  

 2. HASHING THE START KEY

The only place where there is a meaningful SHA1 versus SHA256 determinat

[Proposal] Update and merge User FAQ's from Web ite and mwiiki

[Keith N. McKenna]

Based on extended discussions on this list at: 
http://markmail.org/search/+list:org.apache.incubator.ooo-dev#query:%20list%3Aorg.apache.incubator.ooo-dev+page:1+mid:pkyogj4m45anxuxg+state:results. 
I propose to start merging and updating the User FAQ's from the website 
into the current structure on the mediawiki (mwiki) and updating the 
FAQ's already there by eliminating outdated references to version 1 and 
version 2 and any duplications.


If there are no objections in 72 hours I will start merging the entries 
from the website into the mwiki.


Regards
Keith N. Mckenna

Re: Problem with the installation

[Andrea Pescetti]

S Vilcko wrote:

When I wanted to install your software Apache OpenOficce incubating
3.4.1.Win x86 install cs.exe ...
1/ Why does your software regests unlimited access to my computer?
2/ Why is your software not digitally signed and shouldn’t be trusted?


Hi, indeed the OpenOffice installation needs to operate with full 
privileges and the executable is not digitally signed (even though we 
are considering it for the next release).


You can, however, ensure that you have obtained the "official" 
OpenOffice binaries by checking their MD5SUM: the checksum for

Apache_OpenOffice_incubating_3.4.1_Win_x86_install_cs.exe
is published at
http://www.apache.org/dist/incubator/ooo/files/localized/cs/3.4.1/Apache_OpenOffice_incubating_3.4.1_Win_x86_install_cs.exe.md5
and you can verify it with one of the many tools available for computing 
the MD5 checksum of a downloaded file.


Regards,
  Andrea.

Re: [Proposal] Update and merge User FAQ's from Web ite and mwiiki

[Rob Weir]

On Fri, Dec 7, 2012 at 3:03 PM, Keith N. McKenna
 wrote:
> Based on extended discussions on this list at:
> http://markmail.org/search/+list:org.apache.incubator.ooo-dev#query:%20list%3Aorg.apache.incubator.ooo-dev+page:1+mid:pkyogj4m45anxuxg+state:results.
> I propose to start merging and updating the User FAQ's from the website into
> the current structure on the mediawiki (mwiki) and updating the FAQ's
> already there by eliminating outdated references to version 1 and version 2
> and any duplications.
>
> If there are no objections in 72 hours I will start merging the entries from
> the website into the mwiki.
>

+1.  I think there was general consensus that this was a good idea
from the discussion in the other thread.

Thanks for volunteering to take the lead on this important task.

-Rob

> Regards
> Keith N. Mckenna
>

Re: [Proposal] Update and merge User FAQ's from Web ite and mwiiki

[Keith N. McKenna]

Rob Weir wrote:

On Fri, Dec 7, 2012 at 3:03 PM, Keith N. McKenna
 wrote:

Based on extended discussions on this list at:
http://markmail.org/search/+list:org.apache.incubator.ooo-dev#query:%20list%3Aorg.apache.incubator.ooo-dev+page:1+mid:pkyogj4m45anxuxg+state:results.
I propose to start merging and updating the User FAQ's from the website into
the current structure on the mediawiki (mwiki) and updating the FAQ's
already there by eliminating outdated references to version 1 and version 2
and any duplications.

If there are no objections in 72 hours I will start merging the entries from
the website into the mwiki.



+1.  I think there was general consensus that this was a good idea
from the discussion in the other thread.

Thanks for volunteering to take the lead on this important task.

-Rob


Regards
Keith N. Mckenna




Rob;

I believe there was general consensus in the other thread also, but 
since I am also proposing some major changes to the content and previous 
philosophy of the mwiki also I felt it appropriate to go this route.


Regards
Keith

Re: [RELEASE]: new languages for AOO 3.4.1

[Andrea Pescetti]

On 04/12/2012 Rob Weir wrote:

We should introduce a disconnect here, to avoid 1 million
uses in Poland ignoring your easily ignored caveat and overwhelming
the people.apache.org server.


This specific issue has now been solved by invoking policy (so, we will 
be able to put builds on people.apache.org but we won't link to them 
from the main website), but the problem is not here. The problem is that 
we have had a Polish translation ready for months and that we haven't 
released it yet (even though recent improvements are really huge and 
will allow to avoid long waits in future).


In general, and coming back to the main thread topic, if we have 
millions of people who look for a certain language, we can find 
volunteers for that language, and your brilliant idea to put notices on 
the native-language websites proves it. So the problem is how to use our 
volunteers effectively and motivate them. Ideally, I would like that it 
doesn't take more than two months between the moment someone volunteers 
to complete a language and the official availability of a build 
including his work.


If we try to motivate volunteers and to understand where the obstacles 
are, we can probably make the "all languages" build virtually useless, 
since all relevant languages will have been covered. I've just started a 
discussion on ooo-l10n to check the status of the 19 extra translations 
for which someone volunteered so far. I hope that this will also help in 
finding if the current policy can be improved: after all, OpenOffice has 
(probably) more committers than any other Apache project, it accounts 
for 40% of all Apache web traffic (downloads excluded!) and if we 
identify clear problems with the policy we can definitely initiate 
changes to it.


Regards,
  Andrea.

Re: Completed Infrastructure Module

[Kay Schenk]

Samer--

Thank you so much for keeping us informed about your progress on these
modules...

Right now, this link to OpenOffice's BZ instance seems to work, but
perhaps it didn't for some reason when you tried it.

Thanks for your interest in Apache OpenOffice.

On Thu, Dec 6, 2012 at 7:41 PM, Samer Mansour  wrote:
> Bugzilla link doesn't work, https://issues.apache.org/ooo/, nothing on
> infra twitter about it. also bugzilla link missing on the marketing
> orientation page.



-- 

MzK

“How wrong is it for a woman to expect the man to build the world
 she wants, rather than to create it herself?”

 -- Anais Nin

Re: [RELEASE]: new languages for AOO 3.4.1

[Rob Weir]

On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti  wrote:
> On 04/12/2012 Rob Weir wrote:
>>
>> We should introduce a disconnect here, to avoid 1 million
>> uses in Poland ignoring your easily ignored caveat and overwhelming
>> the people.apache.org server.
>
>
> This specific issue has now been solved by invoking policy (so, we will be
> able to put builds on people.apache.org but we won't link to them from the
> main website), but the problem is not here. The problem is that we have had
> a Polish translation ready for months and that we haven't released it yet
> (even though recent improvements are really huge and will allow to avoid
> long waits in future).
>

So why haven't we released the Polish translation?  I agree that is a
problem, but not one that requires policy to change to solve.

Maybe releases under incubation were a pain the ass.  But the are
relatively easy now.  We should try it sometime...

> In general, and coming back to the main thread topic, if we have millions of
> people who look for a certain language, we can find volunteers for that
> language, and your brilliant idea to put notices on the native-language
> websites proves it. So the problem is how to use our volunteers effectively
> and motivate them. Ideally, I would like that it doesn't take more than two
> months between the moment someone volunteers to complete a language and the
> official availability of a build including his work.
>

Ergo, release more often.  This does not require any policy changes.
It just requires that we release more often.

> If we try to motivate volunteers and to understand where the obstacles are,
> we can probably make the "all languages" build virtually useless, since all
> relevant languages will have been covered. I've just started a discussion on
> ooo-l10n to check the status of the 19 extra translations for which someone
> volunteered so far. I hope that this will also help in finding if the
> current policy can be improved: after all, OpenOffice has (probably) more
> committers than any other Apache project, it accounts for 40% of all Apache
> web traffic (downloads excluded!) and if we identify clear problems with the
> policy we can definitely initiate changes to it.
>

We just need to do some very simple things:

1) When a translation is ready we need to test it.

2) When it is tested, we need to create 1) a source bundle containing
the changed source files, and a 2) a set of binary packages containing
the new installs.

3) We have a 72 hour vote on the incremental source package

4) If the vote passes then we put the new binaries on SourceForge, put
the new source bundle on the Apache mirrors, update the website and
send out an announcement.

This is not hard.   Maybe some one-time upfront work to create
incremental language source bundles on demand.  It is certainly
simpler than trying to get a policy change.

Maybe it would help if someone volunteered to be Release Manager for
language releases between our numbered functional releases?  Then one
person can focus on the major builds, while another person focuses on
getting out these incremental translations.

I think we can go a lot faster on new languages, but IMHO there is no
policy holding us back.  It is just work.

-Rob

> Regards,
>   Andrea.

Re: "dist" move...

[Andrea Pescetti]

On 06/12/2012 Marcus (OOo) wrote:

So, don't we need to switch to
"http://archive.apache.org/dist/openoffice/"; here as well?


It seems that the pre-graduation builds are kept archived under 
/incubator in general and not moved, compare for example PDFBox:

- http://archive.apache.org/dist/incubator/pdfbox/ (pre-graduation releases)
- http://archive.apache.org/dist/pdfbox/ (post-graduation releases)

So the current archive should probably not be moved, but future builds 
(4.0 onwards) will be archived at http://archive.apache.org/dist/openoffice/


Then of course our current archive contains 10 years of files from the 
pre-Apache era which don't fit perfectly in the "incubator" subdir... 
but it's very good to have them archived somewhere at Apache.


Regards,
  Andrea.

calc spreadsheet data validate window: 'Value' field not checked

[Lucas Burson]

Hi,

I'm doing a regression test on a Calc spreadsheet using data validity
for cells. It appears that if you open the validity window (toolbar
Data -> Validity) the 'Value' box isn't checked against the allowed
type. I don't see it in BZ... but I haven't used search enough to be
sure.
Or maybe I'm doing it wrong?

This fails on Win7_32 and Ubuntu_64 for AOO 3.4.1 and 4.0M1 builds. It
must have worked at one point in time since it's a regression test.

1. Create a spreadsheet.
2. Select some group of cells (or a single cell, doesn't matter)
3. On the main toolbar, select 'Data' -> 'Validity...'. The validity
window opens.
4. For the Allow dropdown, select 'Whole Numbers'. Set Data to Equal.
5. In the Value field, enter some non-whole number (like 'm', or '1.2').
6. The illegal value should be rejected but it's not.

Thanks,
Lucas

Re: [RELEASE]: new languages for AOO 3.4.1

[janI]

On 8 December 2012 00:34, Rob Weir  wrote:

> On Fri, Dec 7, 2012 at 5:40 PM, Andrea Pescetti 
> wrote:
> > On 04/12/2012 Rob Weir wrote:
> >>
> >> We should introduce a disconnect here, to avoid 1 million
> >> uses in Poland ignoring your easily ignored caveat and overwhelming
> >> the people.apache.org server.
>
If I may say so, the disconnect is already in place for the danish
translationand I am sure none of us like it. The danish forum has one
simple solution, download LO. What is better that the people server get
swammed (which might lead to a change in policy) or users give up !

> >
> >
> > This specific issue has now been solved by invoking policy (so, we will
> be
> > able to put builds on people.apache.org but we won't link to them from
> the
> > main website), but the problem is not here. The problem is that we have
> had
> > a Polish translation ready for months and that we haven't released it yet
> > (even though recent improvements are really huge and will allow to avoid
> > long waits in future).
>
+1, 2 of the 3 danish volunteers (not including me) have more or less
stopped working due to demotivation...we have not even been able to provide
them with a running version to test their work until very recently.

> >
>
> So why haven't we released the Polish translation?  I agree that is a
> problem, but not one that requires policy to change to solve.
>
> Maybe releases under incubation were a pain the ass.  But the are
> relatively easy now.  We should try it sometime...
>
> > In general, and coming back to the main thread topic, if we have
> millions of
> > people who look for a certain language, we can find volunteers for that
> > language, and your brilliant idea to put notices on the native-language
> > websites proves it. So the problem is how to use our volunteers
> effectively
> > and motivate them. Ideally, I would like that it doesn't take more than
> two
> > months between the moment someone volunteers to complete a language and
> the
> > official availability of a build including his work.
> >
>
> Ergo, release more often.  This does not require any policy changes.
> It just requires that we release more often.
>
or at least just release of the language pack, which should be a lot easier
to vote on (if needed).

>
> > If we try to motivate volunteers and to understand where the obstacles
> are,
> > we can probably make the "all languages" build virtually useless, since
> all
> > relevant languages will have been covered. I've just started a
> discussion on
> > ooo-l10n to check the status of the 19 extra translations for which
> someone
> > volunteered so far. I hope that this will also help in finding if the
> > current policy can be improved: after all, OpenOffice has (probably) more
> > committers than any other Apache project, it accounts for 40% of all
> Apache
> > web traffic (downloads excluded!) and if we identify clear problems with
> the
> > policy we can definitely initiate changes to it.
> >
>
> We just need to do some very simple things:
>
> 1) When a translation is ready we need to test it.
>
This should be, check pootle server review status, and have one volunteer
send an e-mail, that the translation is ok.

>
> 2) When it is tested, we need to create 1) a source bundle containing
> the changed source files, and a 2) a set of binary packages containing
> the new installs.
>
> 3) We have a 72 hour vote on the incremental source package
>
> 4) If the vote passes then we put the new binaries on SourceForge, put
> the new source bundle on the Apache mirrors, update the website and
> send out an announcement.
>
+1 to you procedure.

>
> This is not hard.   Maybe some one-time upfront work to create
> incremental language source bundles on demand.  It is certainly
> simpler than trying to get a policy change.
>
> Maybe it would help if someone volunteered to be Release Manager for
> language releases between our numbered functional releases?  Then one
> person can focus on the major builds, while another person focuses on
> getting out these incremental translations.
>
If I can get help to get started, I would like to volunteer for that part.

>
> I think we can go a lot faster on new languages, but IMHO there is no
> policy holding us back.  It is just work.
>
> -Rob
>
> > Regards,
> >   Andrea.
>