date:20131022

On Tue, Oct 22, 2013 at 4:07 PM, Drew Jensen  wrote:
> Howdy Rob,
>
> Ah trademarks - yes, I agree the Apache OpenOffice should have a TM, a la:
> "IBM® Lotus® Symphony™ is a suite of open source office applications."
>

I've put in a request to get that page updated.

> A couple of quick questions if I may.
> Will the support only be available to those with the IBM connectors? IIRC
> that was the plan  in the past.
>

It is certainly possible to combine IBM Support for Apache OpenOffice
along with a license for IBM Connections or SmartCloud.  In that case
our Connector [1] would be supported as well.

We also have an integration solution for OpenOffice and IBM Enterprise
Content Management [2].

We're exploring other integrations as well.

That said, if a customer wants help with a large, complex, standalone
deployment of Apache OpenOffice, we'll talk with them.   That was also
the case with Symphony.

> Also, does IBM have any plans to list AOO support on the United States GSA
> registry? This was available in the past but not available for the last few
> years.

I have no idea.  Should we?

Regards,

-Rob

[1] 
http://extensions.openoffice.org/en/project/ibm-connections-connector-apache-openoffice

[2] 
http://www-01.ibm.com/software/data/information-agenda/catalog/profiles/OpenOffice_Integration_IBM_ECM.html

> Thanks,
>
> //drew
>
>
> On Mon, Oct 21, 2013 at 7:44 PM, Jörg Schmidt  wrote:
>
>> > From: Rob Weir [mailto:robw...@apache.org]
>>
>> > >
>> > > Sorry, but I think the website does not comply with the
>> > necessary formalities.
>> > >
>> > > Always has been emphasized, these are marked on the
>> > relevant websites trademark of Apache, for example:
>> > >
>> > > "IBM Support for Apache OpenOffice "
>> > >
>> > > and not only:
>> > >
>> > > "IBM Support for Apache OpenOffice"
>> > >
>> >
>> > I think that would be more confusing.
>>
>> Sorry, but appearance is imho not so much the issue here, but rather
>> trademark rights of Apache.
>> Yes, that is formal, but how else should this be handled?
>>
>> > It would suggest the entire
>> > name was a trademark since it is a continuous name with capital
>> > letters.
>>
>> It does not have to be in the headline. Put identification in continuous
>> text, for example in:
>>
>> "IBM® Support for Apache OpenOffice™ offers expert technical support for
>> Apache OpenOffice™, ..."
>>
>> where IBM is already marked with ®.
>>
>>
>>
>>
>> Greetings,
>> Jörg
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Submission for consultants page

On Tue, Oct 22, 2013 at 6:04 PM, Kay Schenk  wrote:
> On Tue, Oct 22, 2013 at 1:07 PM, Drew Jensen 
> wrote:
>
>> Howdy Rob,
>>
>> Ah trademarks - yes, I agree the Apache OpenOffice should have a TM, a la:
>> "IBM® Lotus® Symphony™ is a suite of open source office applications."
>>
>
> FYI on the existing consultant entries
> http://www.openoffice.org/bizdev/consultants.html
>
> none have the TM after Apache OpenOffice, and some don't even have "Apache"
> in front of OpenOffice. So...not sure if we should manually correct these
> already approved submissions.
>

I think the concern is how OpenOffice is referenced on the vendor's
linked website, not on our own website.  All www.openoffice.org pages
are already covered by having the logo in the upper left, since that
has the (TM) symbol.

Regards,

-Rob

> Of course, it's our site so we can do what we want. My point is we should
> be consistent in how OpenOffice is presented in them -- with "Apache" or
> not; with TM after or not.
>
>
>
>>
>> A couple of quick questions if I may.
>> Will the support only be available to those with the IBM connectors? IIRC
>> that was the plan  in the past.
>>
>> Also, does IBM have any plans to list AOO support on the United States GSA
>> registry? This was available in the past but not available for the last few
>> years.
>>
>> Thanks,
>>
>> //drew
>>
>>
>> On Mon, Oct 21, 2013 at 7:44 PM, Jörg Schmidt 
>> wrote:
>>
>> > > From: Rob Weir [mailto:robw...@apache.org]
>> >
>> > > >
>> > > > Sorry, but I think the website does not comply with the
>> > > necessary formalities.
>> > > >
>> > > > Always has been emphasized, these are marked on the
>> > > relevant websites trademark of Apache, for example:
>> > > >
>> > > > "IBM Support for Apache OpenOffice "
>> > > >
>> > > > and not only:
>> > > >
>> > > > "IBM Support for Apache OpenOffice"
>> > > >
>> > >
>> > > I think that would be more confusing.
>> >
>> > Sorry, but appearance is imho not so much the issue here, but rather
>> > trademark rights of Apache.
>> > Yes, that is formal, but how else should this be handled?
>> >
>> > > It would suggest the entire
>> > > name was a trademark since it is a continuous name with capital
>> > > letters.
>> >
>> > It does not have to be in the headline. Put identification in continuous
>> > text, for example in:
>> >
>> > "IBM® Support for Apache OpenOffice™ offers expert technical support for
>> > Apache OpenOffice™, ..."
>> >
>> > where IBM is already marked with ®.
>> >
>> >
>> >
>> >
>> > Greetings,
>> > Jörg
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> > For additional commands, e-mail: dev-h...@openoffice.apache.org
>> >
>> >
>>
>
>
>
> --
> -
> MzK
>
> "There's so much boldness in living life this way ...
>  we did it all, and no one can take it away from us."
> -- Diana Nyad

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Submission for consultants page

2013-10-22 Thread Kay Schenk

On Tue, Oct 22, 2013 at 1:07 PM, Drew Jensen wrote:

> Howdy Rob,
>
> Ah trademarks - yes, I agree the Apache OpenOffice should have a TM, a la:
> "IBM® Lotus® Symphony™ is a suite of open source office applications."
>

FYI on the existing consultant entries
http://www.openoffice.org/bizdev/consultants.html

none have the TM after Apache OpenOffice, and some don't even have "Apache"
in front of OpenOffice. So...not sure if we should manually correct these
already approved submissions.

Of course, it's our site so we can do what we want. My point is we should
be consistent in how OpenOffice is presented in them -- with "Apache" or
not; with TM after or not.



>
> A couple of quick questions if I may.
> Will the support only be available to those with the IBM connectors? IIRC
> that was the plan  in the past.
>
> Also, does IBM have any plans to list AOO support on the United States GSA
> registry? This was available in the past but not available for the last few
> years.
>
> Thanks,
>
> //drew
>
>
> On Mon, Oct 21, 2013 at 7:44 PM, Jörg Schmidt 
> wrote:
>
> > > From: Rob Weir [mailto:robw...@apache.org]
> >
> > > >
> > > > Sorry, but I think the website does not comply with the
> > > necessary formalities.
> > > >
> > > > Always has been emphasized, these are marked on the
> > > relevant websites trademark of Apache, for example:
> > > >
> > > > "IBM Support for Apache OpenOffice "
> > > >
> > > > and not only:
> > > >
> > > > "IBM Support for Apache OpenOffice"
> > > >
> > >
> > > I think that would be more confusing.
> >
> > Sorry, but appearance is imho not so much the issue here, but rather
> > trademark rights of Apache.
> > Yes, that is formal, but how else should this be handled?
> >
> > > It would suggest the entire
> > > name was a trademark since it is a continuous name with capital
> > > letters.
> >
> > It does not have to be in the headline. Put identification in continuous
> > text, for example in:
> >
> > "IBM® Support for Apache OpenOffice™ offers expert technical support for
> > Apache OpenOffice™, ..."
> >
> > where IBM is already marked with ®.
> >
> >
> >
> >
> > Greetings,
> > Jörg
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>



-- 
-
MzK

"There's so much boldness in living life this way ...
 we did it all, and no one can take it away from us."
-- Diana Nyad

Re: [proposal] Patches on Windows

2013-10-22 Thread Andrea Pescetti


Andre Fischer wrote:

I would now like to change the build system, especially the
solenv/bin/make_installer.pl script and its modules, so that the
installation sets it creates can be used without further changes to
create patch sets. I would also like to add the patch creation itself.


This is another feature that users have asked for several years, great 
to see progress here!



More details about the creation of installation sets and patches can be
found in the Wiki [2].


A question I have is what happens to the versionrc file (or equivalent 
on Windows). It contains hard-coded (but customizable at the system 
level) defaults for, e.g., the update URL. Will applying the patch 
overwrite it too?


On one hand, leaving it as it is would create problems since OpenOffice 
would continue to behave as the old version when looking for updates. On 
the other hand, overwriting it would destroy user customizations; but 
this is probably what we are already doing now for full installation sets.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show


On Oct 22, 2013, at 17:33 , Guenter Marxen  
wrote:

> 
> Am 22.10.2013 22:31, schrieb Louis Suárez-Potts:
>>> 
>> @ all (including me, who is lazier than most and even more shameless): 
>> please bottom post. :-)
>> 
>> louis
> 
> Louis, thanks. But I wouldt like a little bit more.

Well, so would we all :-)

> 
> I am very astonished, that on this list with very experienced users nearly 
> _nobody_ follows the netiquette when responding.

?

> 
> I think, that nearly everybody uses a mail client which is able to handle 
> threats.

"Threats"?

Oh, you mean "threads." Sorry, my error. I misread your typo.


> 
> It would be much more easy and time saving (for all) to follow a thread (and 
> participate), when mails are short and not containing all ever given answers.
> 
> Don't take it only as criticism or disapproval but as an "enhancement issue".

Ah. I see. For a moment there I was actually thinking that you were criticizing 
some of us here—and without even a smiley, to show that, Hey, this is really 
not that serious an issue but...
> 
> -- 
> Grüße
> 
> Günter Marxen

Cheers,
Louis
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show

2013-10-22 Thread Guenter Marxen



Am 22.10.2013 22:31, schrieb Louis Suárez-Potts:



@ all (including me, who is lazier than most and even more shameless): please 
bottom post. :-)

louis


Louis, thanks. But I wouldt like a little bit more.

I am very astonished, that on this list with very experienced users 
nearly _nobody_ follows the netiquette when responding.


I think, that nearly everybody uses a mail client which is able to 
handle threats.


It would be much more easy and time saving (for all) to follow a thread 
(and participate), when mails are short and not containing all ever 
given answers.


Don't take it only as criticism or disapproval but as an "enhancement 
issue".


--
Grüße

Günter Marxen


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Possible new open source program

2013-10-22 Thread Hagar Delest


Grisbi is also a good one:
http://www.grisbi.org/
Their site is under maintenance but the application works fine.

Hagar


Le 22/10/2013 00:28, Rob Weir a écrit :


On Mon, Oct 21, 2013 at 6:17 PM, Afshin Karjoo  wrote:

Hello,
I was wondering if you would consider releasing an open source version of 
Microsoft Money that was stopped development in 2009. Having this available for 
multiple operating systems, especially Mac would be great since no good money 
software is available for Mac with the functionality of Microsoft money.


Are you familiar with GnuCash?

http://www.gnucash.org/

-Rob



Thank you for considering this in your future product lineup.
Best Regards,
Afshin Karjoo
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO Security Features without Mozilla

2013-10-22 Thread Andrea Pescetti


Herbert Dürr wrote:

[1] https://issues.apache.org/ooo/show_bug.cgi?id=85356
[2] https://issues.apache.org/ooo/show_bug.cgi?id=63270
[3] https://issues.apache.org/ooo/show_bug.cgi?id=91079
This is an interesting reality check and I'm afraid the project lost
users that depended on that functionality long ago. On the other hand
these facts enable us to kick this non-functioning and unmaintainable
crap out without a serious negative impact.


Count me among those who are very happy to see a large, unmaintained, 
outdated, problematic part of our codebase being removed, and thanks for 
doing so!


But we need to be quite clear in telling users what we will drop by 
extending the "Mozilla removal" from the initial idea of replacing just 
the crypto support to this idea of dropping the Address Book 
functionality too.


The above issues show that functionality had been (and still is) 
crippled, but not that it is 100% broken. Would it be possible to 
extract some short bullet points, or use cases, of what is lost by 
dropping Mozilla at this stage? We could put it early in the draft 
Release Notes and give proper notice to the (hopefully few) users who 
may still depend on it.


Regards,
  Andrea.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show


On 22 Oct 2013, at 16:20 , Drew Jensen  wrote:

> wow, all good stuff guys.
> 
> Turns out the website (show) already lists an ODF mobile reader:
> http://www.appbrain.com/app/openoffice-document-reader/at.tomtasche.reader
> 
> Also, the request from the caller was not about reading ODF files, rather
> creating files using voice-to-text and was looking for someting other then
> Dragon Speak pro (IIRC) on his desktop old XP machine) for use by his
> special needs child.
> So before I, or anyone, writes something on this maybe if the collective
> intelligence on this list could shot some ideas off on the requirement -
> honestly I would not know what to say.
> 
> Thanks,

Yes, the point is to have an editor — that is, something that can create files, 
not just read them, on a mobile.


> 
> //drew
> 
@ all (including me, who is lazier than most and even more shameless): please 
bottom post. :-)

louis



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: AOO on Nexus 7 and the Kim Komando Show

2013-10-22 Thread Drew Jensen

wow, all good stuff guys.

Turns out the website (show) already lists an ODF mobile reader:
http://www.appbrain.com/app/openoffice-document-reader/at.tomtasche.reader

Also, the request from the caller was not about reading ODF files, rather
creating files using voice-to-text and was looking for someting other then
Dragon Speak pro (IIRC) on his desktop old XP machine) for use by his
special needs child.
So before I, or anyone, writes something on this maybe if the collective
intelligence on this list could shot some ideas off on the requirement -
honestly I would not know what to say.

Thanks,

//drew


On Tue, Oct 22, 2013 at 2:40 PM, Louis Suárez-Potts wrote:

>
> On 2013-10-22, at 14:21 , Rob Weir  wrote:
>
> > On Tue, Oct 22, 2013 at 2:15 PM, Louis Suárez-Potts 
> wrote:
> >>
> >> On 2013-10-22, at 14:11 , Rob Weir  wrote:
> >>
> >>> On Tue, Oct 22, 2013 at 1:41 PM, Louis Suárez-Potts 
> wrote:
> 
>  On 2013-10-22, at 13:38 , Rob Weir  wrote:
> 
> > On Mon, Oct 21, 2013 at 9:42 PM, Louis Suárez-Potts <
> lui...@gmail.com> wrote:
> >>
> >> On 2013-10-21, at 18:28 , Ian Lynch  wrote:
> >>
> >>> Given the number of Android devices out there and growing I can
> see a time
> >>> where if its not editable there it won't be worth considering.
> >>
> >> That time is now.
> >
> > The 800-lbs gorilla is Google and their QuickOffice purchase, which
> > they are now making available for free on iOS and Android:
> >
> > https://plus.google.com/+GoogleDrive/posts/Gz5GpSeCW4x
> >
> > I don't think it supports ODF, but otherwise is a strong editor
> suite.
> > So it does make it hard for any new competitor, since they would
> > essentially be competing against a free, fully-featured app.
> 
>  is it a native client?
> 
> >>>
> >>> Yes.
> >>
> >> (BTW, there are no 800 lb. gorillas :-) )
> >>
> >> Okay, but arguendo the mighty weight of Google's omnipresence, I'd be
> curious to learn what kind of uptake there will be of the app. Given their
> deployment of Docs & other Drive tools, I suspect there'll be improvements,
> but erratically.
> >>
> >
> > IMHO there is probably opportunity for an app that is a bit more open
> > in what it connects to.  The free Google apps appear to be bolted to
> > Google Drive.  But an app that supports DropBox, Sky Drive, Google
> > Drive, iCloud, ownCloud, etc., could be interesting.
> >
>
> Indeed. That's why I'm working with Peter of UX Write. He's also quite
> interested in simplifying the process by which a mobile app *would* connect
> to n+1 number of cloud services. Right now, as you note, there is a mess of
> more or less proprietary (or at least idiosyncratic) APIs, protocols, code
> dances that a developer must make bend his app to.
>
>
> What is wanted (by yours truly) is for UX Write to work better with ODF…..
>
> > Regards,
> >
> > -Rob
> >
>
> -louis
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Submission for consultants page

2013-10-22 Thread Drew Jensen

Howdy Rob,

Ah trademarks - yes, I agree the Apache OpenOffice should have a TM, a la:
"IBM® Lotus® Symphony™ is a suite of open source office applications."

A couple of quick questions if I may.
Will the support only be available to those with the IBM connectors? IIRC
that was the plan  in the past.

Also, does IBM have any plans to list AOO support on the United States GSA
registry? This was available in the past but not available for the last few
years.

Thanks,

//drew


On Mon, Oct 21, 2013 at 7:44 PM, Jörg Schmidt  wrote:

> > From: Rob Weir [mailto:robw...@apache.org]
>
> > >
> > > Sorry, but I think the website does not comply with the
> > necessary formalities.
> > >
> > > Always has been emphasized, these are marked on the
> > relevant websites trademark of Apache, for example:
> > >
> > > "IBM Support for Apache OpenOffice "
> > >
> > > and not only:
> > >
> > > "IBM Support for Apache OpenOffice"
> > >
> >
> > I think that would be more confusing.
>
> Sorry, but appearance is imho not so much the issue here, but rather
> trademark rights of Apache.
> Yes, that is formal, but how else should this be handled?
>
> > It would suggest the entire
> > name was a trademark since it is a continuous name with capital
> > letters.
>
> It does not have to be in the headline. Put identification in continuous
> text, for example in:
>
> "IBM® Support for Apache OpenOffice™ offers expert technical support for
> Apache OpenOffice™, ..."
>
> where IBM is already marked with ®.
>
>
>
>
> Greetings,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [announcement] Downtime on forum.o.o

Hi.




On 22 October 2013 16:09, janI  wrote:

> Hi.
>
> The database(s) behind forum.o.o need to be changed and moved to a new
> fast central sql server.
>
> In order to test the changes without disturbing anyone, I have created a
> forum "test" where all needed changes will be done during the coming days.
>
> Thursday 22/10 at 1500 UTC, we will begin moving the each single forum
> database into the EN database (with separate tables for each forum), and
> convert FULLTEXT tables back to myIsam.
>

Typo sorry for the confusion, I mean Thursday 24/10. We do want to give
plenty of warning this time :-)

thx marcus for catching it.

rgds
jan I.


> This process means 10-30 minutes downtime for each forum.
>
> At 1800 UTC, we will stop all forums for about 2hours while moving the db
> to the central sql. We will try to keep the downtime as small as possible.
>
> It is appreciated, if admins test their forums after 2000 UTC. I will be
> available on #asfinfra and on mail, to help with any problems.
>
> Please advice forum users.
>
> Taking the experience from translate.a.o and wiki.o.o a better performance
> and higher stability can be expected.
>
> on behalf of infra
> jan I.
>
>

Re: AOO on Nexus 7 and the Kim Komando Show


On 2013-10-22, at 14:21 , Rob Weir  wrote:

> On Tue, Oct 22, 2013 at 2:15 PM, Louis Suárez-Potts  wrote:
>> 
>> On 2013-10-22, at 14:11 , Rob Weir  wrote:
>> 
>>> On Tue, Oct 22, 2013 at 1:41 PM, Louis Suárez-Potts  
>>> wrote:
 
 On 2013-10-22, at 13:38 , Rob Weir  wrote:
 
> On Mon, Oct 21, 2013 at 9:42 PM, Louis Suárez-Potts  
> wrote:
>> 
>> On 2013-10-21, at 18:28 , Ian Lynch  wrote:
>> 
>>> Given the number of Android devices out there and growing I can see a 
>>> time
>>> where if its not editable there it won't be worth considering.
>> 
>> That time is now.
> 
> The 800-lbs gorilla is Google and their QuickOffice purchase, which
> they are now making available for free on iOS and Android:
> 
> https://plus.google.com/+GoogleDrive/posts/Gz5GpSeCW4x
> 
> I don't think it supports ODF, but otherwise is a strong editor suite.
> So it does make it hard for any new competitor, since they would
> essentially be competing against a free, fully-featured app.
 
 is it a native client?
 
>>> 
>>> Yes.
>> 
>> (BTW, there are no 800 lb. gorillas :-) )
>> 
>> Okay, but arguendo the mighty weight of Google's omnipresence, I'd be 
>> curious to learn what kind of uptake there will be of the app. Given their 
>> deployment of Docs & other Drive tools, I suspect there'll be improvements, 
>> but erratically.
>> 
> 
> IMHO there is probably opportunity for an app that is a bit more open
> in what it connects to.  The free Google apps appear to be bolted to
> Google Drive.  But an app that supports DropBox, Sky Drive, Google
> Drive, iCloud, ownCloud, etc., could be interesting.
> 

Indeed. That's why I'm working with Peter of UX Write. He's also quite 
interested in simplifying the process by which a mobile app *would* connect to 
n+1 number of cloud services. Right now, as you note, there is a mess of more 
or less proprietary (or at least idiosyncratic) APIs, protocols, code dances 
that a developer must make bend his app to.


What is wanted (by yours truly) is for UX Write to work better with ODF…..

> Regards,
> 
> -Rob
> 

-louis
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show

On Tue, Oct 22, 2013 at 2:15 PM, Louis Suárez-Potts  wrote:
>
> On 2013-10-22, at 14:11 , Rob Weir  wrote:
>
>> On Tue, Oct 22, 2013 at 1:41 PM, Louis Suárez-Potts  wrote:
>>>
>>> On 2013-10-22, at 13:38 , Rob Weir  wrote:
>>>
 On Mon, Oct 21, 2013 at 9:42 PM, Louis Suárez-Potts  
 wrote:
>
> On 2013-10-21, at 18:28 , Ian Lynch  wrote:
>
>> Given the number of Android devices out there and growing I can see a 
>> time
>> where if its not editable there it won't be worth considering.
>
> That time is now.

 The 800-lbs gorilla is Google and their QuickOffice purchase, which
 they are now making available for free on iOS and Android:

 https://plus.google.com/+GoogleDrive/posts/Gz5GpSeCW4x

 I don't think it supports ODF, but otherwise is a strong editor suite.
 So it does make it hard for any new competitor, since they would
 essentially be competing against a free, fully-featured app.
>>>
>>> is it a native client?
>>>
>>
>> Yes.
>
> (BTW, there are no 800 lb. gorillas :-) )
>
> Okay, but arguendo the mighty weight of Google's omnipresence, I'd be curious 
> to learn what kind of uptake there will be of the app. Given their deployment 
> of Docs & other Drive tools, I suspect there'll be improvements, but 
> erratically.
>

IMHO there is probably opportunity for an app that is a bit more open
in what it connects to.  The free Google apps appear to be bolted to
Google Drive.  But an app that supports DropBox, Sky Drive, Google
Drive, iCloud, ownCloud, etc., could be interesting.

Regards,

-Rob


> -lsp
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show


On 2013-10-22, at 14:11 , Rob Weir  wrote:

> On Tue, Oct 22, 2013 at 1:41 PM, Louis Suárez-Potts  wrote:
>> 
>> On 2013-10-22, at 13:38 , Rob Weir  wrote:
>> 
>>> On Mon, Oct 21, 2013 at 9:42 PM, Louis Suárez-Potts  
>>> wrote:
 
 On 2013-10-21, at 18:28 , Ian Lynch  wrote:
 
> Given the number of Android devices out there and growing I can see a time
> where if its not editable there it won't be worth considering.
 
 That time is now.
>>> 
>>> The 800-lbs gorilla is Google and their QuickOffice purchase, which
>>> they are now making available for free on iOS and Android:
>>> 
>>> https://plus.google.com/+GoogleDrive/posts/Gz5GpSeCW4x
>>> 
>>> I don't think it supports ODF, but otherwise is a strong editor suite.
>>> So it does make it hard for any new competitor, since they would
>>> essentially be competing against a free, fully-featured app.
>> 
>> is it a native client?
>> 
> 
> Yes.

(BTW, there are no 800 lb. gorillas :-) )

Okay, but arguendo the mighty weight of Google's omnipresence, I'd be curious 
to learn what kind of uptake there will be of the app. Given their deployment 
of Docs & other Drive tools, I suspect there'll be improvements, but 
erratically. 

-lsp


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show

On Tue, Oct 22, 2013 at 1:41 PM, Louis Suárez-Potts  wrote:
>
> On 2013-10-22, at 13:38 , Rob Weir  wrote:
>
>> On Mon, Oct 21, 2013 at 9:42 PM, Louis Suárez-Potts  wrote:
>>>
>>> On 2013-10-21, at 18:28 , Ian Lynch  wrote:
>>>
 Given the number of Android devices out there and growing I can see a time
 where if its not editable there it won't be worth considering.
>>>
>>> That time is now.
>>
>> The 800-lbs gorilla is Google and their QuickOffice purchase, which
>> they are now making available for free on iOS and Android:
>>
>> https://plus.google.com/+GoogleDrive/posts/Gz5GpSeCW4x
>>
>> I don't think it supports ODF, but otherwise is a strong editor suite.
>> So it does make it hard for any new competitor, since they would
>> essentially be competing against a free, fully-featured app.
>
> is it a native client?
>

Yes.

-Rob

> Louis
>>
>> Regards,
>>
>> -Rob
>>
>>> Louis
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO Security Features without Mozilla

2013-10-22 Thread Andrew Rist



On 10/22/2013 7:15 AM, Herbert Dürr wrote:

On 22.10.2013 14:22, Herbert Dürr wrote:

On 22.10.2013 13:46, janI wrote:

On 22 October 2013 13:30, Herbert Dürr  wrote:

[...]
Since issue 91209 the mozilla address books were disabled on Mac
altogether anyway, so on Mac we could rid AOO of its heavy Seamonkey
dependency really soon without removing any features by using NSS
instead
of bundling a large set of Seamonkey libraries.

On the other platforms a very high percentage of our user base 
wouldn't

notice any missing features if the Mozilla address book support was
removed
there too.


I have no problem with that, since it makes our product lighter and
simpler. But for this I think we need user opinions.


Yes, whether we build our next release with the --enable-mozab-module
option or without it is open for discussion. Now if there were
volunteers that implemented extensions for mapping mork/ldap/wab address
books to AOO's SDBC API then the whole mozab module would be superfluous
anyway and the discussion would have only one reasonable result.


A small status update regarding the state of the existing mozilla 
address book integration: Non-anonymous LDAP address books was out of 
order [1] since 2008, the windows address book didn't work since 2006 
if it contained any distribution list [2] and was broken on all now 
supported Microsoft operating systems [3] since at least 2008.


[1] https://issues.apache.org/ooo/show_bug.cgi?id=85356
[2] https://issues.apache.org/ooo/show_bug.cgi?id=63270
[3] https://issues.apache.org/ooo/show_bug.cgi?id=91079

This is an interesting reality check and I'm afraid the project lost 
users that depended on that functionality long ago. On the other hand 
these facts enable us to kick this non-functioning and unmaintainable 
crap out without a serious negative impact.


With these new insights I suggest to remove both the enable-mozilla 
and its eventual replacement enable-mozab-module before losing much 
more time on that topic. The sooner the better.

+1

This should simplify the configure options.  All the mozilla stuff will 
be gone and there will be no more enable/disable mozilla/mozab options - 
right?


A.


Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show


On 2013-10-22, at 13:38 , Rob Weir  wrote:

> On Mon, Oct 21, 2013 at 9:42 PM, Louis Suárez-Potts  wrote:
>> 
>> On 2013-10-21, at 18:28 , Ian Lynch  wrote:
>> 
>>> Given the number of Android devices out there and growing I can see a time
>>> where if its not editable there it won't be worth considering.
>> 
>> That time is now.
> 
> The 800-lbs gorilla is Google and their QuickOffice purchase, which
> they are now making available for free on iOS and Android:
> 
> https://plus.google.com/+GoogleDrive/posts/Gz5GpSeCW4x
> 
> I don't think it supports ODF, but otherwise is a strong editor suite.
> So it does make it hard for any new competitor, since they would
> essentially be competing against a free, fully-featured app.

is it a native client?

Louis
> 
> Regards,
> 
> -Rob
> 
>> Louis
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show

On Mon, Oct 21, 2013 at 9:42 PM, Louis Suárez-Potts  wrote:
>
> On 2013-10-21, at 18:28 , Ian Lynch  wrote:
>
>> Given the number of Android devices out there and growing I can see a time
>> where if its not editable there it won't be worth considering.
>
> That time is now.

The 800-lbs gorilla is Google and their QuickOffice purchase, which
they are now making available for free on iOS and Android:

https://plus.google.com/+GoogleDrive/posts/Gz5GpSeCW4x

I don't think it supports ODF, but otherwise is a strong editor suite.
 So it does make it hard for any new competitor, since they would
essentially be competing against a free, fully-featured app.

Regards,

-Rob

> Louis
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: help for "bundled help"

2013-10-22 Thread Kay Schenk

On Mon, Oct 21, 2013 at 5:13 PM, Ariel Constenla-Haile
wrote:

> Hi,
>
> On Mon, Oct 21, 2013 at 04:57:48PM -0700, Kay Schenk wrote:
> > Should we *try* to migrate to something else?
>
> The Help is available for extension developers [1], "something else"
> would mean an incompatible change, and any incompatible change should
> wait until AOO 5;
>
of course, that "else" could be backwards compatible
> during AOO4 lifetime, but this would overcomplicate development (besides
> that "something else" means writing new code and somebody has to do
> this).
>

OK, good points -- something this major should be reserved for a major
version change. I don't see a new "help" environment as being backward
compatible, or  a need for something like that as currently "help" for a
version is already bundled with it.



>
> [1]
> http://wiki.openoffice.org/wiki/Documentation/DevGuide/Extensions/Help_Content
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>



-- 
-
MzK

"There's so much boldness in living life this way ...
 we did it all, and no one can take it away from us."
-- Diana Nyad

Re: AOO Security Features without Mozilla

2013-10-22 Thread Pedro Giffuni


Hello;

Really nice to see nss being split soon. I hope we can use an external 
nss too as the one we include internally is somewhat outdated and 
potentially insecure.


While on the subject of replacing mozilla addressbook, just thought I'd
remind about the analysis done by Andre while we were working on IP
clearance [1].

Back then I also found the Mulberry vCard library [2] that is under an 
Apache License. Interfacing it with AOO is a completely different

matter though :-(.

Regards,

Pedro.

[1] 
https://cwiki.apache.org/confluence/display/OOOUSERS/IP_Clearance_Address+Book


[2] http://trac.mulberrymail.com/repos/browser/vCard

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO on Nexus 7 and the Kim Komando Show

2013-10-22 Thread Ian Lynch

One consideration is power consumption, cost is another, multi-vendor is
another. We can also learn from history that volumes determine markets and
the Android/Arm combo is sweeping the planet. It's not in our power to stop
that any more than is would be to ignore Windows on desktops. If Intel
can't stop it I doubt we have any chance of doing so. If "AOO/odf" editing
wants to get out there as far as possible it needs to go to any large
volume platform and Android/ARM already looks set to be the biggest. Looks
like its easier for ARM to scale up and keep costs and power consumption
down than it is for x86 to scale down without melting your device or a hole
in your pocket ;-).

On 22 October 2013 03:22, Fernando Cassia  wrote:

> On Mon, Oct 21, 2013 at 7:28 PM, Ian Lynch  wrote:
>
> > Given the number of Android devices out there and growing I can see a
> time
> > where if its not editable there it won't be worth considering.
> >
>
> I think it's worth educationg consumers that "tablet form factor" does not
> necessarily mean "Android OS on a ARM CPU."
>
> I'm using a MSI Windpad 110W with 10" screen and AMD Fusion CPU/GPU (APU).
> I can run any darn x86 OS I want on it, Win7, Ubuntu Linux, Fedora Linux,
> FreeBSD.
>
> There are many other x86 tablets with CPUs from AMD and Intel.
> Why people continue restricting themselves to ARM/Android devices (besides
> 50%+ lower cost) when they could have the power of a full laptop on a
> tablet form factor is beyond me...
>
> FC
>
>
> --
> During times of Universal Deceit, telling the truth becomes a revolutionary
> act
> Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
> Revolucionario
> - George Orwell
>

-- 
Ian

Ofqual Accredited IT Qualifications 

Headline points in the 2014 and 2015 school league tables

www.theINGOTs.org +44 (0)1827 305940

The Learning Machine Limited, Reg Office, Unit 4D Gagarin, Lichfield
Road Industrial Estate, Tamworth, Staffordshire, B79 7GN. Reg No:
05560797, Registered in England and Wales.

Re: [Bug 122235] Connection fails with "502 Error reading from remote server"

On 22 October 2013 16:41, Oliver-Rainer Wittmann
wrote:

> Hi,
>
> On 22.10.2013 10:04, Rainer Bielefeld wrote:
>
>> Hi,
>>
>> it's really daunting that nobody cares!
>>
>>
> I care, but only as a user of our Bugzilla instance being frustrated when
> I need Bugzilla in the morning (European time zone).
>
> It seems that we need to involve ASF Infra as I do not believe that this
> scheduled outage every day is controlled by us.
>

Just checked, there are no outstanding issues with aoo-bz, except its very
slow because it has not yet had the db moved. The "scheduled outage" is
unknown, but could be the backup which runs very early morning (europe
time).

rgds
jan I.

Ps. once again it was suggested that we move to jira.

>
> Best regards, Oliver.
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [Bug 122235] Connection fails with "502 Error reading from remote server"

2013-10-22 Thread Oliver-Rainer Wittmann


Hi,

On 22.10.2013 10:04, Rainer Bielefeld wrote:

Hi,

it's really daunting that nobody cares!



I care, but only as a user of our Bugzilla instance being frustrated 
when I need Bugzilla in the morning (European time zone).


It seems that we need to involve ASF Infra as I do not believe that this 
scheduled outage every day is controlled by us.


Best regards, Oliver.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: AOO Security Features without Mozilla

On 22 October 2013 16:15, Herbert Dürr  wrote:

> On 22.10.2013 14:22, Herbert Dürr wrote:
>
>> On 22.10.2013 13:46, janI wrote:
>>
>>> On 22 October 2013 13:30, Herbert Dürr  wrote:
>>>
 [...]
 Since issue 91209 the mozilla address books were disabled on Mac
 altogether anyway, so on Mac we could rid AOO of its heavy Seamonkey
 dependency really soon without removing any features by using NSS
 instead
 of bundling a large set of Seamonkey libraries.

 On the other platforms a very high percentage of our user base wouldn't
 notice any missing features if the Mozilla address book support was
 removed
 there too.

  I have no problem with that, since it makes our product lighter and
>>> simpler. But for this I think we need user opinions.
>>>
>>
>> Yes, whether we build our next release with the --enable-mozab-module
>> option or without it is open for discussion. Now if there were
>> volunteers that implemented extensions for mapping mork/ldap/wab address
>> books to AOO's SDBC API then the whole mozab module would be superfluous
>> anyway and the discussion would have only one reasonable result.
>>
>
> A small status update regarding the state of the existing mozilla address
> book integration: Non-anonymous LDAP address books was out of order [1]
> since 2008, the windows address book didn't work since 2006 if it contained
> any distribution list [2] and was broken on all now supported Microsoft
> operating systems [3] since at least 2008.
>
> [1] 
> https://issues.apache.org/ooo/**show_bug.cgi?id=85356
> [2] 
> https://issues.apache.org/ooo/**show_bug.cgi?id=63270
> [3] 
> https://issues.apache.org/ooo/**show_bug.cgi?id=91079
>
> This is an interesting reality check and I'm afraid the project lost users
> that depended on that functionality long ago. On the other hand these facts
> enable us to kick this non-functioning and unmaintainable crap out without
> a serious negative impact.
>
I dont hope we have too many more "surprises" like that.


>
> With these new insights I suggest to remove both the enable-mozilla and
> its eventual replacement enable-mozab-module before losing much more time
> on that topic. The sooner the better.
>
+1.

rgds
jan I.


>
> Herbert
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: AOO Security Features without Mozilla

2013-10-22 Thread Herbert Dürr


On 22.10.2013 14:22, Herbert Dürr wrote:

On 22.10.2013 13:46, janI wrote:

On 22 October 2013 13:30, Herbert Dürr  wrote:

[...]
Since issue 91209 the mozilla address books were disabled on Mac
altogether anyway, so on Mac we could rid AOO of its heavy Seamonkey
dependency really soon without removing any features by using NSS
instead
of bundling a large set of Seamonkey libraries.

On the other platforms a very high percentage of our user base wouldn't
notice any missing features if the Mozilla address book support was
removed
there too.


I have no problem with that, since it makes our product lighter and
simpler. But for this I think we need user opinions.


Yes, whether we build our next release with the --enable-mozab-module
option or without it is open for discussion. Now if there were
volunteers that implemented extensions for mapping mork/ldap/wab address
books to AOO's SDBC API then the whole mozab module would be superfluous
anyway and the discussion would have only one reasonable result.


A small status update regarding the state of the existing mozilla 
address book integration: Non-anonymous LDAP address books was out of 
order [1] since 2008, the windows address book didn't work since 2006 if 
it contained any distribution list [2] and was broken on all now 
supported Microsoft operating systems [3] since at least 2008.


[1] https://issues.apache.org/ooo/show_bug.cgi?id=85356
[2] https://issues.apache.org/ooo/show_bug.cgi?id=63270
[3] https://issues.apache.org/ooo/show_bug.cgi?id=91079

This is an interesting reality check and I'm afraid the project lost 
users that depended on that functionality long ago. On the other hand 
these facts enable us to kick this non-functioning and unmaintainable 
crap out without a serious negative impact.


With these new insights I suggest to remove both the enable-mozilla and 
its eventual replacement enable-mozab-module before losing much more 
time on that topic. The sooner the better.


Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

[announcement] Downtime on forum.o.o

Hi.

The database(s) behind forum.o.o need to be changed and moved to a new fast
central sql server.

In order to test the changes without disturbing anyone, I have created a
forum "test" where all needed changes will be done during the coming days.

Thursday 22/10 at 1500 UTC, we will begin moving the each single forum
database into the EN database (with separate tables for each forum), and
convert FULLTEXT tables back to myIsam.

This process means 10-30 minutes downtime for each forum.

At 1800 UTC, we will stop all forums for about 2hours while moving the db
to the central sql. We will try to keep the downtime as small as possible.

It is appreciated, if admins test their forums after 2000 UTC. I will be
available on #asfinfra and on mail, to help with any problems.

Please advice forum users.

Taking the experience from translate.a.o and wiki.o.o a better performance
and higher stability can be expected.

on behalf of infra
jan I.

Re: easy task

On Sun, Oct 20, 2013 at 1:38 AM, Glenn Harvey Liwanag
 wrote:
> Another +1 here. I'm actually just reading the e-mails ever since I got
> here to see if I can get something from those.
>
> I checked https://issues.apache.org/ooo/query.cgi?format=report-table and
> https://issues.apache.org/ooo/describecomponents.cgi
>
> Maybe adding some hot links to common bug lists would help everyone a lot
> and so that the search is not limited by product category. Links to stuff
> like: Easy, Intermediate, Difficult, Popular,. Giving new ones like us a
> big list of things that we think can handle, I think, is much efficient
> that just us looking for things to work on by category. It's just a
> suggestion at best though.
>

The Introduction to Development page has links to BZ views that list
the "easy" (27 bugs) and "simple" (16 bugs) categories.

http://openoffice.apache.org/orientation/intro-development.html

Generally, these bugs are a good start, as a next step after
downloading the code and successfully building.

Regards,

-Rob

> On Sun, Oct 20, 2013 at 12:41 PM, akshika akalanka <
> akshikaakala...@gmail.com> wrote:
>
>> I would +1 that idea Wlada, you are really thoughtful. It would definitely
>> help new developers like us. Thank you. :-)
>>  On Oct 20, 2013 7:40 AM, "Vladislav Stevanovic" <
>> stevanovicvladis...@gmail.com> wrote:
>>
>> > >It seems it's a bit hidden
>> >
>> > It is a bit hidden, indeed! And my impression of  this page is distant,
>> > cold tone. No emotions, no pictures to show where is problem, there is no
>> > directly approach to the potential developers.  Also, I can not see list
>> of
>> > features what we want to see in AOO in near future, or maybe this list
>> > existed on other place. These features we can split on "easy task",
>> > "moderate" and "heavy task". Maybe
>> > We must improved this. If this is not a problem, I have a  good will to
>> try
>> > something in that area with some ideas. Is it OK?
>> >
>> > Regards,
>> > Wlada
>> >
>> >
>> >
>> > 2013/10/19 Andrea Pescetti 
>> >
>> > > Vladislav Stevanovic wrote:
>> > >
>> > >> Does exist some list of easy tasks that some potential developer for
>> AOO
>> > >> can see? Idea is that this sort of  list MUST exist, if we want to see
>> > >> here
>> > >> new developers...
>> > >>
>> > >
>> > > It seems it's a bit hidden, but we've had it for months.
>> > >
>> > > Usually we point new developers to
>> > >
>> > > http://openoffice.apache.org/**orientation/intro-development.**html<
>> > http://openoffice.apache.org/orientation/intro-development.html>
>> > >
>> > > that has a chapter named "Finding Easy Tasks" with two predefined
>> > Bugzilla
>> > > queries for "easy" (really introductory) and "simple" tasks.
>> > >
>> > > There are currently more than 40 tasks ready there.
>> > >
>> > > Regards,
>> > >   Andrea.
>> > >
>> > >
>> --**--**-
>> > > To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
>> > dev-unsubscr...@openoffice.apache.org>
>> > > For additional commands, e-mail: dev-h...@openoffice.apache.org
>> > >
>> > >
>> >
>>
>
>
> *
> *

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: New Committer: YuZhen Fan (fanyuzhen)

2013-10-22 Thread Siva

Congratulations for YuZhen
Fan.

> On October 22, 2013 at 9:40
> AM Rob Weir
>  wrote:
> 
> 
> The Project Management
> Committee (PMC) for Apache
> OpenOffice has asked
> YuZhen Fan to become a
> committer and we are pleased
> to announce
> that she has accepted and
> taken the ID "fanyuzhen".
> 
> A warm welcome to YuZhen !
> 
> Regards,
> 
> Rob, on behalf of the Apache
> OpenOffice PMC
> 
> -
> To unsubscribe, e-mail:
> dev-unsubscr...@openoffice.apache.org
> For additional commands,
> e-mail:
> dev-h...@openoffice.apache.org
> 
~~
Thank you very much for your
time.
~~
Siva P,
Acquisition Coordinator,
Talent Infotech Inc,
304 Canterbury Way,
Severna Park, MD 21146.

Phone: 443-722-2543.
Fax: 425-696-9020.
~~

Re: easy task

On Sat, Oct 19, 2013 at 10:09 PM, Vladislav Stevanovic
 wrote:
>>It seems it's a bit hidden
>
> It is a bit hidden, indeed! And my impression of  this page is distant,
> cold tone. No emotions, no pictures to show where is problem, there is no
> directly approach to the potential developers.  Also, I can not see list of
> features what we want to see in AOO in near future, or maybe this list
> existed on other place. These features we can split on "easy task",
> "moderate" and "heavy task". Maybe

We've used our blog, social media, conference presentations, etc., to
reach out for volunteers, including developers.  For example, this is
a blog post we did a while ago:

https://blogs.apache.org/OOo/entry/call_for_development_volunteers

As you can see, it refers the reader to the website for more
information.  When we see a new person on the mailing list we point
them to these orientation pages as well.

Feature ideas change quickly, so we don't put those on the website.
But they show up in two other places:

1) Issues in Bugzilla with the assigned to field set to a person.

2) On the CWiki we have a page to collect ideas for releases and to
track the release plan.  You can see the 4.1 page here:

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Release+Planning

> We must improved this. If this is not a problem, I have a  good will to try
> something in that area with some ideas. Is it OK?
>

Any of these things can be improved, certainly.

Regards,

-Rob

> Regards,
> Wlada
>
>
>
> 2013/10/19 Andrea Pescetti 
>
>> Vladislav Stevanovic wrote:
>>
>>> Does exist some list of easy tasks that some potential developer for AOO
>>> can see? Idea is that this sort of  list MUST exist, if we want to see
>>> here
>>> new developers...
>>>
>>
>> It seems it's a bit hidden, but we've had it for months.
>>
>> Usually we point new developers to
>>
>> http://openoffice.apache.org/**orientation/intro-development.**html
>>
>> that has a chapter named "Finding Easy Tasks" with two predefined Bugzilla
>> queries for "easy" (really introductory) and "simple" tasks.
>>
>> There are currently more than 40 tasks ready there.
>>
>> Regards,
>>   Andrea.
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@openoffice.**apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

New Committer: YuZhen Fan (fanyuzhen)

The Project Management Committee (PMC) for Apache OpenOffice has asked
YuZhen Fan to become a committer and we are pleased to announce
that she has accepted and taken the ID "fanyuzhen".

A warm welcome to YuZhen !

Regards,

Rob, on behalf of the Apache OpenOffice PMC

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Service Maintenance for pootle and AOO wiki

2013-10-22 Thread Tony Stevenson


On 21 Oct 2013, at 17:27, Andrea Pescetti  wrote:

> Tony Stevenson wrote:
>> Andrea Pescetti wrote on Mon, Oct 21, 2013 at 04:52:14PM +0200:
>>> Please tell us when the migration is complete so that we can remove
>>> the warning.
>> The service is back. IMO it also quicker. Immediate difference is that
>> Wiki VM is only consuming 500 MB of RAM now, before it was using 2.8GB.
> 
> OK, thank you! It seems that in the end interruption of service was minimal. 
> I've removed the note from the home page. Of course, for the next maintenance 
> operations, including the forum, please give us some more time to inform 
> users.

Further to this, the pootle service has now been migrated to the central DB 
service and converted to InnoDB.  Many thanks to Jan for his help again, 
performance looks increased by a factor of 7 according to a sample of page load 
times based on different activities. 


> 
> Regards,
>  Andrea.


Cheers,
Tony

--
Tony Stevenson

t...@pc-tony.com
pct...@apache.org

http://www.pc-tony.com

GPG - 1024D/51047D66
--







-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [proposal] Patches on Windows

On 22 October 2013 13:48, Andre Fischer  wrote:

> On 22.10.2013 13:32, janI wrote:
>
>> On 22 October 2013 13:10, Andre Fischer  wrote:
>>
>>  On 22.10.2013 12:20, janI wrote:
>>>
>>>  On 22 October 2013 11:48, Andre Fischer  wrote:

   Hello everybody,

> At the moment we provide full installation sets for every release and
> for
> all platforms and languages.  An installation set has a typical size of
> roughly 150MB.  The size of the actual changes is typically much
> smaller.
>Using patches instead of full installation sets would considerably
> reduce
> the amount of data that has to be downloaded by users.  For new users
> without existing installation of OpenOffice we probably still need the
> full
> installation sets.
>
>   Would this also be an opertunity, to look at how we release
> languages ?
>
 I have tested making an installation set that contain all released
 languages, it has a rough size of 200Mb, which is a lot friendlier than
 <#
 langauges> * 150Mb, and gives international users (like me) the option
 to
 switch UI.

  Friendlier to our servers, but not to our users.  But this problem is
>>> orthogonal to creating patches.  And we have to distinguish what language
>>> support we are talking about:
>>> - UI language of the installer
>>>
>>>  We still need the installer in every language, and that the bit that I
>> have
>> not done. I envised a fork in the installer so it loads the OS language of
>> the host.
>>
>
> There are two parts to this: setup.exe and the included msi.  Adding
> support to the msi might be easier than we think.  At least the 'File'
> table has a 'Language' column.  I think the table that contains the UI
> messages that are displayed during the installation has something similar.
>  If this column acts as a filter then all we have to do is add entries for
> all languages and let the msi select the right ones automatically.  The
> setup.exe is build by the NSIS installer creator.  I don't know if and how
> it supports multiple languages.
>
>
>
>>  - UI language of OpenOffice
>>>
>>>  that is what I have done with --with-lang
>>
>>  - Languages supported by spell checker et al.
>>>
>> that is simple files added to the distribution, and the main reason for
>> the
>> extra 50Mb.
>>
>
> Yes, but how do we decide which of the many spell checkers to install?
>  All of them all the time?  Or only a subset, depending on the locale?


You are right, we might just want to install the UI part with the local
spell checker, then the user can choose to add spell checkers as needed.


>
>
>
>> Why do you see this as a disadvantage to our users.
>>
>
> I only see the larger download as disadvantage.  I don't know how many
> people really would want to have even more spell checkers installed on
> their system and would accept an increase of 1/3 of our already large
> installation sets.
> The main reason for using patches instead of full installation sets is
> their reduced size.  Including all available languages might reduce that
> advantage.
>

You misunderstand me. I am 100% for patches !!

with all available languages in the install set, we will only need 1 patch,
so in total its an advantage.

But as said earlier, I agree with "small steps" first make the patches
work, then consider the rest.

rgds
jan I.


>
> -Andre
>
>
>> Many users have multiple languages for spell checkers etc installed, and
>> some (especially people working internationally) also have multiple UI
>> languages.
>>
>> rgds
>> jan I.
>>
>>
>>>
>>>  All I miss is to pursuade the installer to choose the right default UI
 language.



   Note that such patches can only be made for minor or micro releases.

>Major releases would still be full installation sets.
>
> I have worked in the past months on finding out how our build system
> has
> to be modified in order to create patch sets on Windows.  This has
> resulted
> in a set of conditions [1] that have to be fulfilled by the
> installation
> sets.  One example of a condition that we currently don't fulfill is
> that
> files must not be deleted in minor or micro releases.
>
> Up to now I have taken two full installation sets and then tweaked the
> newer one until I was able to
> a) successfully create an .msp patch file and
> b) successfully apply it to an OpenOffice that was installed by the
> older
> install set.
>
> I would now like to change the build system, especially the solenv/bin/
> make_installer.pl script and its modules, so that the installation
> sets
> it creates can be used without further changes to create patch sets.  I
> would also like to add the patch creation itself.
>
>   +1, I have added a single comment on the wiki page about zero length
>
 files.

 please consider making the patch mecha

Re: AOO Security Features without Mozilla

2013-10-22 Thread Herbert Dürr


On 22.10.2013 13:46, janI wrote:

On 22 October 2013 13:30, Herbert Dürr  wrote:

[...]
Since issue 91209 the mozilla address books were disabled on Mac
altogether anyway, so on Mac we could rid AOO of its heavy Seamonkey
dependency really soon without removing any features by using NSS instead
of bundling a large set of Seamonkey libraries.

On the other platforms a very high percentage of our user base wouldn't
notice any missing features if the Mozilla address book support was removed
there too.


I have no problem with that, since it makes our product lighter and
simpler. But for this I think we need user opinions.


Yes, whether we build our next release with the --enable-mozab-module 
option or without it is open for discussion. Now if there were 
volunteers that implemented extensions for mapping mork/ldap/wab address 
books to AOO's SDBC API then the whole mozab module would be superfluous 
anyway and the discussion would have only one reasonable result.



[...]

For the mozilla address books I plan to add the option
 --enable-mozab-module
to replace the then way too broadly named option
 --enable-mozilla


Just to be sure, you will not add the option, but rename the other option,
so we only have --enable-mozab-module ?


Up to now the enable-mozilla option was for enabling security and the 
mozilla address book. With the rework only the "mozab" aspect would 
remain and so the option should be renamed to be more concise.



Until the replacements outlined above have been developed this new option
will allow bundling of the old Seamonkey binaries for users that depend on
its address book support.


please keep the number of new options and changes in configure as low as
possible, that helps me :-)


I intend to keep it as simple and concise as possible.


Its a good initative, which I highly support, and once you have integrated
it into trunk I will update my branches.


Thanks!


Actually the rejuvenate branch seems to be a bigger candidate for
conflicting changes, but we will take that when its ready.


Yes, working on and improving the rejuvenate branch is very important. 
The security-enabling branch removemoz is a prerequisite though as the 
old seamonkey is not nearly ready to be compiled on modern platforms. 
Investing energy in resurrecting the obsolete version or replacing it 
with a more modern version would be a waste of time, especially when 
there is a way for us to kill this incredibly heavy dependency for good.


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [proposal] Patches on Windows


On 22.10.2013 13:40, janI wrote:

On 22 October 2013 13:31, Andre Fischer  wrote:


I don't know much about language support of installer and patches but I
see a problem with spell checking.  Spell checking and grammar checking is
done by extensions which have to be registered at first start.  That can
not be done directly by the installer or a patch. They can at best trigger
such a registration at first start.  And the whole area of first start and
extension registration is a really dark area of our code.
I would like to first try to get the patch creation to work for single
language installs and then we can think about how to handle multiple
languages.

+1 keep it simple, but keep multiple languages in mind, I think we very

soon need to address that issue.

I dont understand "first start", I just added a new spell checker to my
running AOO so I would think it can be done anytime.


You, and every user can, but not the installer or a patch.  The 
installer relies on OpenOffice to check on its first start if there are 
any extensions that have to be installed.  The same might work after 
applying a patch.


-Andre

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [proposal] Patches on Windows


On 22.10.2013 13:32, janI wrote:

On 22 October 2013 13:10, Andre Fischer  wrote:


On 22.10.2013 12:20, janI wrote:


On 22 October 2013 11:48, Andre Fischer  wrote:

  Hello everybody,

At the moment we provide full installation sets for every release and for
all platforms and languages.  An installation set has a typical size of
roughly 150MB.  The size of the actual changes is typically much smaller.
   Using patches instead of full installation sets would considerably
reduce
the amount of data that has to be downloaded by users.  For new users
without existing installation of OpenOffice we probably still need the
full
installation sets.

  Would this also be an opertunity, to look at how we release languages ?

I have tested making an installation set that contain all released
languages, it has a rough size of 200Mb, which is a lot friendlier than <#
langauges> * 150Mb, and gives international users (like me) the option to
switch UI.


Friendlier to our servers, but not to our users.  But this problem is
orthogonal to creating patches.  And we have to distinguish what language
support we are talking about:
- UI language of the installer


We still need the installer in every language, and that the bit that I have
not done. I envised a fork in the installer so it loads the OS language of
the host.


There are two parts to this: setup.exe and the included msi.  Adding 
support to the msi might be easier than we think.  At least the 'File' 
table has a 'Language' column.  I think the table that contains the UI 
messages that are displayed during the installation has something 
similar.  If this column acts as a filter then all we have to do is add 
entries for all languages and let the msi select the right ones 
automatically.  The setup.exe is build by the NSIS installer creator.  I 
don't know if and how it supports multiple languages.





- UI language of OpenOffice


that is what I have done with --with-lang


- Languages supported by spell checker et al.

that is simple files added to the distribution, and the main reason for the
extra 50Mb.


Yes, but how do we decide which of the many spell checkers to install?  
All of them all the time?  Or only a subset, depending on the locale?




Why do you see this as a disadvantage to our users.


I only see the larger download as disadvantage.  I don't know how many 
people really would want to have even more spell checkers installed on 
their system and would accept an increase of 1/3 of our already large 
installation sets.
The main reason for using patches instead of full installation sets is 
their reduced size.  Including all available languages might reduce that 
advantage.


-Andre



Many users have multiple languages for spell checkers etc installed, and
some (especially people working internationally) also have multiple UI
languages.

rgds
jan I.





All I miss is to pursuade the installer to choose the right default UI
language.



  Note that such patches can only be made for minor or micro releases.

   Major releases would still be full installation sets.

I have worked in the past months on finding out how our build system has
to be modified in order to create patch sets on Windows.  This has
resulted
in a set of conditions [1] that have to be fulfilled by the installation
sets.  One example of a condition that we currently don't fulfill is that
files must not be deleted in minor or micro releases.

Up to now I have taken two full installation sets and then tweaked the
newer one until I was able to
a) successfully create an .msp patch file and
b) successfully apply it to an OpenOffice that was installed by the older
install set.

I would now like to change the build system, especially the solenv/bin/
make_installer.pl script and its modules, so that the installation sets
it creates can be used without further changes to create patch sets.  I
would also like to add the patch creation itself.

  +1, I have added a single comment on the wiki page about zero length

files.

please consider making the patch mechanism in its own module.


  For this I propose and seek lazy consensus for the following changes:

1. When a new release is made, create data files that are added to our
version control system (semi automatically) that allow us on the next
release to check and/or enforce the conditions.

2. Before the next release is made, read the data files of the previous
release and check and/or enforce the conditions.

3. When a new minor or micro release is made, first create the full
installation sets, then create patches.
 Besides the data files mentioned above, this also requires access to
the installation sets of the previous release.

4. Cleanup of the logging mechanism used by make_installer.pl and its
modules, so that I can better debug the existing and the new code.


Most of the proposed changes have a low impact on the current creation of
installation sets.  They basically only add new features (collecting
information about a relea

Re: AOO Security Features without Mozilla

On 22 October 2013 13:30, Herbert Dürr  wrote:

> About everyone who ever built OpenOffice in the last couple of years
> wondered why an almost complete (and obsolete/unmaintained/ancient) version
> of Mozilla Seamonkey was needed when building OpenOffice with its security
> features enabled such as support for password protected documents.
>
> The branch "Remove_MOZ" shows that it is possible to get rid of that
> dependency and I suggest we do that as soon as possible. The branch was
> inappropriately named because it is only about the removing the mozilla
> dependency of security related stuff.
>
+1

>
> But the old Seamonkey binaries still have another purpose: for now they
> are needed for providing its own address books that used to be in the
> "Mork" format. It also provides access to some address books [1] such as
> LDAP, Outlook and Outlook Express.
>
> [1] http://www.openoffice.org/dba/**specifications/address_book_**
> architecture.html
>
> Other address sources such as JDBC, ODBC, CSV-Text, MySql and dBase
> already work without Mozilla. On Mac the native Address Book is already
> supported directly.
>
> Since issue 91209 the mozilla address books were disabled on Mac
> altogether anyway, so on Mac we could rid AOO of its heavy Seamonkey
> dependency really soon without removing any features by using NSS instead
> of bundling a large set of Seamonkey libraries.
>
> On the other platforms a very high percentage of our user base wouldn't
> notice any missing features if the Mozilla address book support was removed
> there too.
>
I have no problem with that, since it makes our product lighter and
simpler. But for this I think we need user opinions.


>
> Developing mozilla-less replacements should be possible and this would
> remove a lot of complexity. As a first idea the replacements could be
> implemented as extensions using something like [2] for LDAP, [3] for Mork
> and [4] for WAB if there was an UNO API to facility that support. Comparing
> the complexity of the scripts below vs the complexities and maintenance
> headaches the ancient Seamonkey and its XPCOM<->UNO bridge is like
> comparing the weight of mice to elephants...
>
> [2] http://www.python-ldap.org/
> [3] https://bug241438.bugzilla.**mozilla.org/attachment.cgi?id=**
> 175024&action=view
> [4] http://stackoverflow.com/**questions/11538550/retrieving-**
> outlook-contacts-via-python
>
> But splitting off the security dependency is much more important. I plan
> to integrate the changes needed for that soon. They will be enabled either
> with
> --enable-nss-module
> or with the more general option
> --enable-category-b

+1 to the --enable-category-b option

> For the mozilla address books I plan to add the option
> --enable-mozab-module
> to replace the then way too broadly named option
> --enable-mozilla
>
Just to be sure, you will not add the option, but rename the other option,
so we only have --enable-mozab-module ?


> Until the replacements outlined above have been developed this new option
> will allow bundling of the old Seamonkey binaries for users that depend on
> its address book support.
>
please keep the number of new options and changes in configure as low as
possible, that helps me :-)

Its a good initative, which I highly support, and once you have integrated
it into trunk I will update my branches.

Actually the rejuvenate branch seems to be a bigger candidate for
conflicting changes, but we will take that when its ready.

rgds
jan I.



>
> Herbert
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [proposal] Patches on Windows

On 22 October 2013 13:31, Andre Fischer  wrote:

> On 22.10.2013 13:08, Rob Weir wrote:
>
>> On Tue, Oct 22, 2013 at 6:20 AM, janI  wrote:
>>
>>> On 22 October 2013 11:48, Andre Fischer  wrote:
>>>
>>>  Hello everybody,

 At the moment we provide full installation sets for every release and
 for
 all platforms and languages.  An installation set has a typical size of
 roughly 150MB.  The size of the actual changes is typically much
 smaller.
   Using patches instead of full installation sets would considerably
 reduce
 the amount of data that has to be downloaded by users.  For new users
 without existing installation of OpenOffice we probably still need the
 full
 installation sets.

  Would this also be an opertunity, to look at how we release languages ?
>>>
>>>  That would certainly have an even greater benefit when combined.
>>
>> If we don't refactor how we distribute languages we'd need many patch
>> files, one for each language/platform combination.
>>
>>  I have tested making an installation set that contain all released
>>> languages, it has a rough size of 200Mb, which is a lot friendlier than
>>> <#
>>> langauges> * 150Mb, and gives international users (like me) the option to
>>> switch UI.
>>>
>>> All I miss is to pursuade the installer to choose the right default UI
>>> language.
>>>
>>>
>>>
>>>  Note that such patches can only be made for minor or micro releases.
   Major releases would still be full installation sets.

 I have worked in the past months on finding out how our build system has
 to be modified in order to create patch sets on Windows.  This has
 resulted
 in a set of conditions [1] that have to be fulfilled by the installation
 sets.  One example of a condition that we currently don't fulfill is
 that
 files must not be deleted in minor or micro releases.

 Up to now I have taken two full installation sets and then tweaked the
 newer one until I was able to
 a) successfully create an .msp patch file and
 b) successfully apply it to an OpenOffice that was installed by the
 older
 install set.

 I would now like to change the build system, especially the solenv/bin/
 make_installer.pl script and its modules, so that the installation sets
 it creates can be used without further changes to create patch sets.  I
 would also like to add the patch creation itself.

  +1, I have added a single comment on the wiki page about zero length
>>> files.
>>>
>>> please consider making the patch mechanism in its own module.
>>>
>>>
>>>  For this I propose and seek lazy consensus for the following changes:

 1. When a new release is made, create data files that are added to our
 version control system (semi automatically) that allow us on the next
 release to check and/or enforce the conditions.

 2. Before the next release is made, read the data files of the previous
 release and check and/or enforce the conditions.

 3. When a new minor or micro release is made, first create the full
 installation sets, then create patches.
 Besides the data files mentioned above, this also requires access to
 the installation sets of the previous release.

 4. Cleanup of the logging mechanism used by make_installer.pl and its
 modules, so that I can better debug the existing and the new code.

>> At some point we'd need to think about how users find and get these
>> patches.  The current mechanism notifies them about the update and
>> sends them to www.openoffice.org/download or to an NL page.  The
>> Javascript logic recommends what download to get.   We'd need to
>> distinguish new downloads from patches.
>>
>
> The update notifications could link directly to patches when notifying a
> minor or micro release.  After all, they originate from an installed office.
>
> Only users that go to our download page have to make a choice between full
> installation and patch.
>
>
>
>> Also, perhaps complications if someone has installed AOO with lang A +
>> lang pack B.  How is this patched?   There is a huge number of
>> combinations there.  Jan's idea of a combined 200MB install with all
>> languages sounds simpler, though larger.
>>
>
> Maybe I should point out that the creation of installation and patch sets
> on Windows is an amazingly complex task, even for the current single
> language install.  Then, as I have said already in an earlier mail, we have
> to distinguish between
>
>
> - UI language of the installer
> - UI language of OpenOffice
> - supported languages for spell checking etc.
>
>
> I don't know much about language support of installer and patches but I
> see a problem with spell checking.  Spell checking and grammar checking is
> done by extensions which have to be registered at first start.  That can
> not be done directly by the installer or a patch. They can at best trigger
> su

Re: [proposal] Patches on Windows

On 22 October 2013 13:10, Andre Fischer  wrote:

> On 22.10.2013 12:20, janI wrote:
>
>> On 22 October 2013 11:48, Andre Fischer  wrote:
>>
>>  Hello everybody,
>>>
>>> At the moment we provide full installation sets for every release and for
>>> all platforms and languages.  An installation set has a typical size of
>>> roughly 150MB.  The size of the actual changes is typically much smaller.
>>>   Using patches instead of full installation sets would considerably
>>> reduce
>>> the amount of data that has to be downloaded by users.  For new users
>>> without existing installation of OpenOffice we probably still need the
>>> full
>>> installation sets.
>>>
>>>  Would this also be an opertunity, to look at how we release languages ?
>>
>> I have tested making an installation set that contain all released
>> languages, it has a rough size of 200Mb, which is a lot friendlier than <#
>> langauges> * 150Mb, and gives international users (like me) the option to
>> switch UI.
>>
>
> Friendlier to our servers, but not to our users.  But this problem is
> orthogonal to creating patches.  And we have to distinguish what language
> support we are talking about:
> - UI language of the installer
>
We still need the installer in every language, and that the bit that I have
not done. I envised a fork in the installer so it loads the OS language of
the host.

> - UI language of OpenOffice
>
that is what I have done with --with-lang

> - Languages supported by spell checker et al.

that is simple files added to the distribution, and the main reason for the
extra 50Mb.

Why do you see this as a disadvantage to our users.

Many users have multiple languages for spell checkers etc installed, and
some (especially people working internationally) also have multiple UI
languages.

rgds
jan I.

>
>
>
>> All I miss is to pursuade the installer to choose the right default UI
>> language.
>>
>>
>>
>>  Note that such patches can only be made for minor or micro releases.
>>>   Major releases would still be full installation sets.
>>>
>>> I have worked in the past months on finding out how our build system has
>>> to be modified in order to create patch sets on Windows.  This has
>>> resulted
>>> in a set of conditions [1] that have to be fulfilled by the installation
>>> sets.  One example of a condition that we currently don't fulfill is that
>>> files must not be deleted in minor or micro releases.
>>>
>>> Up to now I have taken two full installation sets and then tweaked the
>>> newer one until I was able to
>>> a) successfully create an .msp patch file and
>>> b) successfully apply it to an OpenOffice that was installed by the older
>>> install set.
>>>
>>> I would now like to change the build system, especially the solenv/bin/
>>> make_installer.pl script and its modules, so that the installation sets
>>> it creates can be used without further changes to create patch sets.  I
>>> would also like to add the patch creation itself.
>>>
>>>  +1, I have added a single comment on the wiki page about zero length
>> files.
>>
>> please consider making the patch mechanism in its own module.
>>
>>
>>  For this I propose and seek lazy consensus for the following changes:
>>>
>>> 1. When a new release is made, create data files that are added to our
>>> version control system (semi automatically) that allow us on the next
>>> release to check and/or enforce the conditions.
>>>
>>> 2. Before the next release is made, read the data files of the previous
>>> release and check and/or enforce the conditions.
>>>
>>> 3. When a new minor or micro release is made, first create the full
>>> installation sets, then create patches.
>>> Besides the data files mentioned above, this also requires access to
>>> the installation sets of the previous release.
>>>
>>> 4. Cleanup of the logging mechanism used by make_installer.pl and its
>>> modules, so that I can better debug the existing and the new code.
>>>
>>>
>>> Most of the proposed changes have a low impact on the current creation of
>>> installation sets.  They basically only add new features (collecting
>>> information about a release, adding it to the VCS,  reading the
>>> information
>>> on next release, checking conditions, creating patches).  However, some
>>> conditions can be enforced automatically (like using the same uuids for
>>> components in one release and the next) and that can introduce
>>> regressions,
>>> ie break installation sets.  But I think the danger of that is not bigger
>>> than with many other new features or bug fixes.  I don't expect conflicts
>>> with build system changes made or proposed by Jan.
>>>
>>>  Go for it, if you do in trunk, I can merge it into my branches.
>>
>> I also very little conflict with my build system work, like maybe 1-2
>> changed makefiles. But thats no serious conflicts, and more me being aware
>> of the changes.
>>
>
> Thanks.  When I eventually check in the changes I will report the details.
>
>
>
>>
>>
>>> More details about the creation of

Re: [proposal] Patches on Windows


On 22.10.2013 13:08, Rob Weir wrote:

On Tue, Oct 22, 2013 at 6:20 AM, janI  wrote:

On 22 October 2013 11:48, Andre Fischer  wrote:


Hello everybody,

At the moment we provide full installation sets for every release and for
all platforms and languages.  An installation set has a typical size of
roughly 150MB.  The size of the actual changes is typically much smaller.
  Using patches instead of full installation sets would considerably reduce
the amount of data that has to be downloaded by users.  For new users
without existing installation of OpenOffice we probably still need the full
installation sets.


Would this also be an opertunity, to look at how we release languages ?


That would certainly have an even greater benefit when combined.

If we don't refactor how we distribute languages we'd need many patch
files, one for each language/platform combination.


I have tested making an installation set that contain all released
languages, it has a rough size of 200Mb, which is a lot friendlier than <#
langauges> * 150Mb, and gives international users (like me) the option to
switch UI.

All I miss is to pursuade the installer to choose the right default UI
language.




Note that such patches can only be made for minor or micro releases.
  Major releases would still be full installation sets.

I have worked in the past months on finding out how our build system has
to be modified in order to create patch sets on Windows.  This has resulted
in a set of conditions [1] that have to be fulfilled by the installation
sets.  One example of a condition that we currently don't fulfill is that
files must not be deleted in minor or micro releases.

Up to now I have taken two full installation sets and then tweaked the
newer one until I was able to
a) successfully create an .msp patch file and
b) successfully apply it to an OpenOffice that was installed by the older
install set.

I would now like to change the build system, especially the solenv/bin/
make_installer.pl script and its modules, so that the installation sets
it creates can be used without further changes to create patch sets.  I
would also like to add the patch creation itself.


+1, I have added a single comment on the wiki page about zero length files.

please consider making the patch mechanism in its own module.



For this I propose and seek lazy consensus for the following changes:

1. When a new release is made, create data files that are added to our
version control system (semi automatically) that allow us on the next
release to check and/or enforce the conditions.

2. Before the next release is made, read the data files of the previous
release and check and/or enforce the conditions.

3. When a new minor or micro release is made, first create the full
installation sets, then create patches.
Besides the data files mentioned above, this also requires access to
the installation sets of the previous release.

4. Cleanup of the logging mechanism used by make_installer.pl and its
modules, so that I can better debug the existing and the new code.



At some point we'd need to think about how users find and get these
patches.  The current mechanism notifies them about the update and
sends them to www.openoffice.org/download or to an NL page.  The
Javascript logic recommends what download to get.   We'd need to
distinguish new downloads from patches.


The update notifications could link directly to patches when notifying a 
minor or micro release.  After all, they originate from an installed office.


Only users that go to our download page have to make a choice between 
full installation and patch.




Also, perhaps complications if someone has installed AOO with lang A +
lang pack B.  How is this patched?   There is a huge number of
combinations there.  Jan's idea of a combined 200MB install with all
languages sounds simpler, though larger.


Maybe I should point out that the creation of installation and patch 
sets on Windows is an amazingly complex task, even for the current 
single language install.  Then, as I have said already in an earlier 
mail, we have to distinguish between


- UI language of the installer
- UI language of OpenOffice
- supported languages for spell checking etc.


I don't know much about language support of installer and patches but I 
see a problem with spell checking.  Spell checking and grammar checking 
is done by extensions which have to be registered at first start.  That 
can not be done directly by the installer or a patch. They can at best 
trigger such a registration at first start.  And the whole area of first 
start and extension registration is a really dark area of our code.
I would like to first try to get the patch creation to work for single 
language installs and then we can think about how to handle multiple 
languages.


-Andre



Regards,

-Rob



Most of the proposed changes have a low impact on the current creation of
installation sets.  They basically only add new features (collecting
informati

AOO Security Features without Mozilla

2013-10-22 Thread Herbert Dürr

About everyone who ever built OpenOffice in the last couple of years 
wondered why an almost complete (and obsolete/unmaintained/ancient) 
version of Mozilla Seamonkey was needed when building OpenOffice with 
its security features enabled such as support for password protected 
documents.


The branch "Remove_MOZ" shows that it is possible to get rid of that 
dependency and I suggest we do that as soon as possible. The branch was 
inappropriately named because it is only about the removing the mozilla 
dependency of security related stuff.


But the old Seamonkey binaries still have another purpose: for now they 
are needed for providing its own address books that used to be in the 
"Mork" format. It also provides access to some address books [1] such as 
LDAP, Outlook and Outlook Express.


[1] 
http://www.openoffice.org/dba/specifications/address_book_architecture.html


Other address sources such as JDBC, ODBC, CSV-Text, MySql and dBase 
already work without Mozilla. On Mac the native Address Book is already 
supported directly.


Since issue 91209 the mozilla address books were disabled on Mac 
altogether anyway, so on Mac we could rid AOO of its heavy Seamonkey 
dependency really soon without removing any features by using NSS 
instead of bundling a large set of Seamonkey libraries.


On the other platforms a very high percentage of our user base wouldn't 
notice any missing features if the Mozilla address book support was 
removed there too.


Developing mozilla-less replacements should be possible and this would 
remove a lot of complexity. As a first idea the replacements could be 
implemented as extensions using something like [2] for LDAP, [3] for 
Mork and [4] for WAB if there was an UNO API to facility that support. 
Comparing the complexity of the scripts below vs the complexities and 
maintenance headaches the ancient Seamonkey and its XPCOM<->UNO bridge 
is like comparing the weight of mice to elephants...


[2] http://www.python-ldap.org/
[3] 
https://bug241438.bugzilla.mozilla.org/attachment.cgi?id=175024&action=view
[4] 
http://stackoverflow.com/questions/11538550/retrieving-outlook-contacts-via-python


But splitting off the security dependency is much more important. I plan 
to integrate the changes needed for that soon. They will be enabled 
either with

--enable-nss-module
or with the more general option
--enable-category-b
For the mozilla address books I plan to add the option
--enable-mozab-module
to replace the then way too broadly named option
--enable-mozilla
Until the replacements outlined above have been developed this new 
option will allow bundling of the old Seamonkey binaries for users that 
depend on its address book support.


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: New committer: Burak Yavuz (bourock)

2013-10-22 Thread ßouЯock™ ღ

Thank you very much. I am happy to be with this huge family and thank you for 
this offer and accept me. 
Best Wishes
Burak Yavuz

> Date: Sun, 20 Oct 2013 19:06:14 +0200
> From: pesce...@apache.org
> To: dev@openoffice.apache.org
> CC: bour...@apache.org
> Subject: New committer: Burak Yavuz (bourock)
> 
> The Project Management Committee (PMC) for Apache OpenOffice has asked
> Burak Yavuz to become a committer and we are pleased to announce
> that he has accepted and taken the ID "bourock".
> 
> A warm welcome to Burak !
> 
> Regards,
> 
> Andrea, on behalf of the Apache OpenOffice PMC

Re: [proposal] Patches on Windows


On 22.10.2013 12:20, janI wrote:

On 22 October 2013 11:48, Andre Fischer  wrote:


Hello everybody,

At the moment we provide full installation sets for every release and for
all platforms and languages.  An installation set has a typical size of
roughly 150MB.  The size of the actual changes is typically much smaller.
  Using patches instead of full installation sets would considerably reduce
the amount of data that has to be downloaded by users.  For new users
without existing installation of OpenOffice we probably still need the full
installation sets.


Would this also be an opertunity, to look at how we release languages ?

I have tested making an installation set that contain all released
languages, it has a rough size of 200Mb, which is a lot friendlier than <#
langauges> * 150Mb, and gives international users (like me) the option to
switch UI.


Friendlier to our servers, but not to our users.  But this problem is 
orthogonal to creating patches.  And we have to distinguish what 
language support we are talking about:

- UI language of the installer
- UI language of OpenOffice
- Languages supported by spell checker et al.



All I miss is to pursuade the installer to choose the right default UI
language.




Note that such patches can only be made for minor or micro releases.
  Major releases would still be full installation sets.

I have worked in the past months on finding out how our build system has
to be modified in order to create patch sets on Windows.  This has resulted
in a set of conditions [1] that have to be fulfilled by the installation
sets.  One example of a condition that we currently don't fulfill is that
files must not be deleted in minor or micro releases.

Up to now I have taken two full installation sets and then tweaked the
newer one until I was able to
a) successfully create an .msp patch file and
b) successfully apply it to an OpenOffice that was installed by the older
install set.

I would now like to change the build system, especially the solenv/bin/
make_installer.pl script and its modules, so that the installation sets
it creates can be used without further changes to create patch sets.  I
would also like to add the patch creation itself.


+1, I have added a single comment on the wiki page about zero length files.

please consider making the patch mechanism in its own module.



For this I propose and seek lazy consensus for the following changes:

1. When a new release is made, create data files that are added to our
version control system (semi automatically) that allow us on the next
release to check and/or enforce the conditions.

2. Before the next release is made, read the data files of the previous
release and check and/or enforce the conditions.

3. When a new minor or micro release is made, first create the full
installation sets, then create patches.
Besides the data files mentioned above, this also requires access to
the installation sets of the previous release.

4. Cleanup of the logging mechanism used by make_installer.pl and its
modules, so that I can better debug the existing and the new code.


Most of the proposed changes have a low impact on the current creation of
installation sets.  They basically only add new features (collecting
information about a release, adding it to the VCS,  reading the information
on next release, checking conditions, creating patches).  However, some
conditions can be enforced automatically (like using the same uuids for
components in one release and the next) and that can introduce regressions,
ie break installation sets.  But I think the danger of that is not bigger
than with many other new features or bug fixes.  I don't expect conflicts
with build system changes made or proposed by Jan.


Go for it, if you do in trunk, I can merge it into my branches.

I also very little conflict with my build system work, like maybe 1-2
changed makefiles. But thats no serious conflicts, and more me being aware
of the changes.


Thanks.  When I eventually check in the changes I will report the details.






More details about the creation of installation sets and patches can be
found in the Wiki [2].


I really like the idea, that brings us one step closer to a more
installation.


Thanks.  After I looked at the make_installer.pl script I toyed with the 
idea of reimplementing it completely.  But that would require too much 
time.  So I will cope with 40 characters long identifiers like 
'$scpactionsinproductlanguageresolvedarrayref'.  But maybe I will clean 
up things like sort algorithms that make bubblesort look fast (see 
sorting_array_of_hashes() in solenv/bin/modules/installer/sorter.pm).  
That are 20 lines of bad code that can be replaced by a single short 
line of Perl code that is much more expressive.


-Andre



thx for taking this initative.

rgds
jan I.



Regards,
Andre


[1] http://wiki.openoffice.org/**wiki/Building_installation_**
packages#Conditions_for_**creating_patches

Re: [proposal] Patches on Windows

On Tue, Oct 22, 2013 at 6:20 AM, janI  wrote:
> On 22 October 2013 11:48, Andre Fischer  wrote:
>
>> Hello everybody,
>>
>> At the moment we provide full installation sets for every release and for
>> all platforms and languages.  An installation set has a typical size of
>> roughly 150MB.  The size of the actual changes is typically much smaller.
>>  Using patches instead of full installation sets would considerably reduce
>> the amount of data that has to be downloaded by users.  For new users
>> without existing installation of OpenOffice we probably still need the full
>> installation sets.
>>
>
> Would this also be an opertunity, to look at how we release languages ?
>

That would certainly have an even greater benefit when combined.

If we don't refactor how we distribute languages we'd need many patch
files, one for each language/platform combination.

> I have tested making an installation set that contain all released
> languages, it has a rough size of 200Mb, which is a lot friendlier than <#
> langauges> * 150Mb, and gives international users (like me) the option to
> switch UI.
>
> All I miss is to pursuade the installer to choose the right default UI
> language.
>
>
>
>>
>> Note that such patches can only be made for minor or micro releases.
>>  Major releases would still be full installation sets.
>>
>> I have worked in the past months on finding out how our build system has
>> to be modified in order to create patch sets on Windows.  This has resulted
>> in a set of conditions [1] that have to be fulfilled by the installation
>> sets.  One example of a condition that we currently don't fulfill is that
>> files must not be deleted in minor or micro releases.
>>
>> Up to now I have taken two full installation sets and then tweaked the
>> newer one until I was able to
>> a) successfully create an .msp patch file and
>> b) successfully apply it to an OpenOffice that was installed by the older
>> install set.
>>
>> I would now like to change the build system, especially the solenv/bin/
>> make_installer.pl script and its modules, so that the installation sets
>> it creates can be used without further changes to create patch sets.  I
>> would also like to add the patch creation itself.
>>
>
> +1, I have added a single comment on the wiki page about zero length files.
>
> please consider making the patch mechanism in its own module.
>
>
>>
>> For this I propose and seek lazy consensus for the following changes:
>>
>> 1. When a new release is made, create data files that are added to our
>> version control system (semi automatically) that allow us on the next
>> release to check and/or enforce the conditions.
>>
>> 2. Before the next release is made, read the data files of the previous
>> release and check and/or enforce the conditions.
>>
>> 3. When a new minor or micro release is made, first create the full
>> installation sets, then create patches.
>>Besides the data files mentioned above, this also requires access to
>> the installation sets of the previous release.
>>
>> 4. Cleanup of the logging mechanism used by make_installer.pl and its
>> modules, so that I can better debug the existing and the new code.
>>


At some point we'd need to think about how users find and get these
patches.  The current mechanism notifies them about the update and
sends them to www.openoffice.org/download or to an NL page.  The
Javascript logic recommends what download to get.   We'd need to
distinguish new downloads from patches.

Also, perhaps complications if someone has installed AOO with lang A +
lang pack B.  How is this patched?   There is a huge number of
combinations there.  Jan's idea of a combined 200MB install with all
languages sounds simpler, though larger.

Regards,

-Rob


>>
>> Most of the proposed changes have a low impact on the current creation of
>> installation sets.  They basically only add new features (collecting
>> information about a release, adding it to the VCS,  reading the information
>> on next release, checking conditions, creating patches).  However, some
>> conditions can be enforced automatically (like using the same uuids for
>> components in one release and the next) and that can introduce regressions,
>> ie break installation sets.  But I think the danger of that is not bigger
>> than with many other new features or bug fixes.  I don't expect conflicts
>> with build system changes made or proposed by Jan.
>>
>
> Go for it, if you do in trunk, I can merge it into my branches.
>
> I also very little conflict with my build system work, like maybe 1-2
> changed makefiles. But thats no serious conflicts, and more me being aware
> of the changes.
>
>
>>
>>
>> More details about the creation of installation sets and patches can be
>> found in the Wiki [2].
>>
>
> I really like the idea, that brings us one step closer to a more
> installation.
>
> thx for taking this initative.
>
> rgds
> jan I.
>
>
>>
>> Regards,
>> Andre
>>
>>
>> [1] http://wiki.openoffice.org/**wiki/Building_

Re: Service Maintenance for pootle and AOO wiki

On 22 October 2013 12:47, imacat  wrote:

> On 2013/10/22 16:10, imacat said:
> > On 2013/10/22 15:42, janI said:
> >> On 22 October 2013 03:02, imacat  wrote:
> >>> On 2013/10/22 02:37, janI said:
>  On 21 October 2013 18:39, Tony Stevenson  wrote:
> > Andrea Pescetti wrote on Mon, Oct 21, 2013 at 06:27:50PM +0200:
> >> Tony Stevenson wrote:
> >>> Andrea Pescetti wrote on Mon, Oct 21, 2013 at 04:52:14PM +0200:
>  Imacat (admin) has responded to my question if help is wanted, answer
> was
>  that it would be be fine if infra does it (like me) and offered to
> help.
> 
>  If we think along these lines, my plan would be the following:
> >>>
> >>> You can ignore me if my help is not needed.  But, still,
> >>
> >> I would never ignore a helping hand, and especially not a qualifed one
> as
> >> yours.
> >
> > Ah...  That is totally unnecessary. ^^;
> >
>  1) Thursday evening (16-22 UTC), I wil combine the single forum
> databases
>  into the EN database. This will mean short breaks on the single forum,
>  about 10min each (to copy the tables).
>   If time permits, I will convert the FULLTEXT back to MyIsam.
> >>> That's 0-6 UTC+8 here.  I have works on Friday.  I can stay up to
> at
> >>> most 19 UTC (3 UTC+8), but not after that.
> >>
> >> ok, lets do this in another way, please select 2 forums (that have the
> >> lowest usage) from the db list below:
> >>
> >> | en |
> >> | es |
> >> | fr |
> >> | hu |
> >> | it |
> >> | ja |
> >> | nl |
> >> | pl |
> >> | vi |
> >> | zh |
> >> ++
> >>
> >> Then I will move tables in these 2 and convert the FULLTEXT tables, as
> soon
> >> as I hear from you, and then you can test. Please give me a UTC time,
> where
> >> you can test (today/tomorrow), then I do the changes just before that
> time.
> >
> > Ah... it's embarrassing that, I will travel to another city later to
> > deliver an OpenOffice macro class for two days, and will return before
> > Thursday evening (16-22 UTC). ^^;  That's the earliest time I'm
> > available this week.
> >
> > And, currently, VI has the lowest traffic.  But we have to notify
> > Phan first.
>
> But I suppose this is the time "back up" or "cover" is for. :p  You
> may ask RGB or Phan for help on this.
>

thx, I have already asked Phan, with ref. to RGB as well.

I am btw making a test forum, http://forum.openoffice.org/test/forum so I
can test the table changes without disturbing anyone. I have copied the EN
db for that purpose.

rgds
jan I.


> >> If it works with these 2 forums, I feel more secure with the rest, and
> >> maybe Ricardo can do a check on them since he is in the same TZ.
> >>
> >>
> >>
> >>> And what do you mean by "combining short forum databases into the
> EN
> >>> databases"?  So we will only have EN database in the future?
> >>>
> >>
> >> Yes, and it will problaly be called "forumsaoodb".
> >>
> >> Remark, this is not a problem because all tables (in use) have the
> naming
> >> standard:
> >>  phpbb__
> >>
> >> if you look e.g. in IT, you will see
> >> | phpbb_it_sessions_keys|
> >> | phpbb_it_sitelist |
> >> | phpbb_it_smilies  |
> >>
> >>
> >> There are 2 databases I dont understand at the moment:
> >>
> >> | ps_helper  |
> >> | test   |
> >>
> >> any ideas ?
> >
> > The "ps_helper" database:
> >
> > https://www.google.com.tw/#q=ps_helper+mysql
> >
> > The "test" database can be safely ignored.  It's a standard MySQL
> > database for testing purpose.  When installing Perl DBD::mysql library,
> > we need a database to test if DBD::mysql is working.  There should
> > always a database named "test" (although some DB admins prefer to remove
> > it), but you do not need to bother with its contents.
> >
> >>
> >>
> >>>
>  2) Friday morning (8-11 UTC) I will convert tables. This happens
> online,
>  and only means slow system while I do it.
> >>>
> >>> That is 16-19 UTC+8.  Normally I would be stuck in the traffic
> going
> >>> home at this time on Fridays, but I could stay in the office if
> necessary.
> >>>
> >>
> >>  see above.
> >>
> >>
>  3) Friday afternoon (15 UTC, depending on pctony), we can take the
> forums
>  down for approx 2hours to move the databases.
> >>>
> >>> That would be perfect for me.
> >>>
> >> it would for me too, but pctony has to go to hospital with his kid, so
> we
> >> try to see if we can do it thursday (24/10).
> >>
> >> I would really apriciate your help with the first 2 forums, to make a
> more
> >> thorough test. And then hope that ricardo could do a smoke test on the
> >> others.
> >>
> >> This is of course a service that infra provides so if you want it
> >> postponed, we will have to find  a way.
> >>
> >>
> >>>
> >>> And also, please add the date (1

Re: Service Maintenance for pootle and AOO wiki

2013-10-22 Thread imacat

On 2013/10/22 16:10, imacat said:
> On 2013/10/22 15:42, janI said:
>> On 22 October 2013 03:02, imacat  wrote:
>>> On 2013/10/22 02:37, janI said:
 On 21 October 2013 18:39, Tony Stevenson  wrote:
> Andrea Pescetti wrote on Mon, Oct 21, 2013 at 06:27:50PM +0200:
>> Tony Stevenson wrote:
>>> Andrea Pescetti wrote on Mon, Oct 21, 2013 at 04:52:14PM +0200:
 Imacat (admin) has responded to my question if help is wanted, answer was
 that it would be be fine if infra does it (like me) and offered to help.

 If we think along these lines, my plan would be the following:
>>>
>>> You can ignore me if my help is not needed.  But, still,
>>
>> I would never ignore a helping hand, and especially not a qualifed one as
>> yours.
> 
> Ah...  That is totally unnecessary. ^^;
> 
 1) Thursday evening (16-22 UTC), I wil combine the single forum databases
 into the EN database. This will mean short breaks on the single forum,
 about 10min each (to copy the tables).
  If time permits, I will convert the FULLTEXT back to MyIsam.
>>> That's 0-6 UTC+8 here.  I have works on Friday.  I can stay up to at
>>> most 19 UTC (3 UTC+8), but not after that.
>>
>> ok, lets do this in another way, please select 2 forums (that have the
>> lowest usage) from the db list below:
>>
>> | en |
>> | es |
>> | fr |
>> | hu |
>> | it |
>> | ja |
>> | nl |
>> | pl |
>> | vi |
>> | zh |
>> ++
>>
>> Then I will move tables in these 2 and convert the FULLTEXT tables, as soon
>> as I hear from you, and then you can test. Please give me a UTC time, where
>> you can test (today/tomorrow), then I do the changes just before that time.
> 
> Ah... it's embarrassing that, I will travel to another city later to
> deliver an OpenOffice macro class for two days, and will return before
> Thursday evening (16-22 UTC). ^^;  That's the earliest time I'm
> available this week.
> 
> And, currently, VI has the lowest traffic.  But we have to notify
> Phan first.

But I suppose this is the time "back up" or "cover" is for. :p  You
may ask RGB or Phan for help on this.

>> If it works with these 2 forums, I feel more secure with the rest, and
>> maybe Ricardo can do a check on them since he is in the same TZ.
>>
>>
>>
>>> And what do you mean by "combining short forum databases into the EN
>>> databases"?  So we will only have EN database in the future?
>>>
>>
>> Yes, and it will problaly be called "forumsaoodb".
>>
>> Remark, this is not a problem because all tables (in use) have the naming
>> standard:
>>  phpbb__
>>
>> if you look e.g. in IT, you will see
>> | phpbb_it_sessions_keys|
>> | phpbb_it_sitelist |
>> | phpbb_it_smilies  |
>>
>>
>> There are 2 databases I dont understand at the moment:
>>
>> | ps_helper  |
>> | test   |
>>
>> any ideas ?
> 
> The "ps_helper" database:
> 
> https://www.google.com.tw/#q=ps_helper+mysql
> 
> The "test" database can be safely ignored.  It's a standard MySQL
> database for testing purpose.  When installing Perl DBD::mysql library,
> we need a database to test if DBD::mysql is working.  There should
> always a database named "test" (although some DB admins prefer to remove
> it), but you do not need to bother with its contents.
> 
>>
>>
>>>
 2) Friday morning (8-11 UTC) I will convert tables. This happens online,
 and only means slow system while I do it.
>>>
>>> That is 16-19 UTC+8.  Normally I would be stuck in the traffic going
>>> home at this time on Fridays, but I could stay in the office if necessary.
>>>
>>
>>  see above.
>>
>>
 3) Friday afternoon (15 UTC, depending on pctony), we can take the forums
 down for approx 2hours to move the databases.
>>>
>>> That would be perfect for me.
>>>
>> it would for me too, but pctony has to go to hospital with his kid, so we
>> try to see if we can do it thursday (24/10).
>>
>> I would really apriciate your help with the first 2 forums, to make a more
>> thorough test. And then hope that ricardo could do a smoke test on the
>> others.
>>
>> This is of course a service that infra provides so if you want it
>> postponed, we will have to find  a way.
>>
>>
>>>
>>> And also, please add the date (10/24, 10/25).  It's confusing to
>>> guess if Friday is 10/25 or 11/1.  (And normally I would bet on 11/1 as
>>> 10/25 is very close.)
>>>
>>
>> Sorry about that, good idea.
>>
>> rgds
>> jan I.
>>
>>>

 In order to finalize the database changes Thursday and move friday, we
>>> need
 someone with access to all forums to help with the test.

 Could this be an acceptable plan ?  The time is needed, but if preferred
>>> I
 can do it friday or saturday evening instead (depending on pctony).

 rgds
 jan I.



>>>

Re: [proposal] Patches on Windows

On 22 October 2013 11:48, Andre Fischer  wrote:

> Hello everybody,
>
> At the moment we provide full installation sets for every release and for
> all platforms and languages.  An installation set has a typical size of
> roughly 150MB.  The size of the actual changes is typically much smaller.
>  Using patches instead of full installation sets would considerably reduce
> the amount of data that has to be downloaded by users.  For new users
> without existing installation of OpenOffice we probably still need the full
> installation sets.
>

Would this also be an opertunity, to look at how we release languages ?

I have tested making an installation set that contain all released
languages, it has a rough size of 200Mb, which is a lot friendlier than <#
langauges> * 150Mb, and gives international users (like me) the option to
switch UI.

All I miss is to pursuade the installer to choose the right default UI
language.



>
> Note that such patches can only be made for minor or micro releases.
>  Major releases would still be full installation sets.
>
> I have worked in the past months on finding out how our build system has
> to be modified in order to create patch sets on Windows.  This has resulted
> in a set of conditions [1] that have to be fulfilled by the installation
> sets.  One example of a condition that we currently don't fulfill is that
> files must not be deleted in minor or micro releases.
>
> Up to now I have taken two full installation sets and then tweaked the
> newer one until I was able to
> a) successfully create an .msp patch file and
> b) successfully apply it to an OpenOffice that was installed by the older
> install set.
>
> I would now like to change the build system, especially the solenv/bin/
> make_installer.pl script and its modules, so that the installation sets
> it creates can be used without further changes to create patch sets.  I
> would also like to add the patch creation itself.
>

+1, I have added a single comment on the wiki page about zero length files.

please consider making the patch mechanism in its own module.


>
> For this I propose and seek lazy consensus for the following changes:
>
> 1. When a new release is made, create data files that are added to our
> version control system (semi automatically) that allow us on the next
> release to check and/or enforce the conditions.
>
> 2. Before the next release is made, read the data files of the previous
> release and check and/or enforce the conditions.
>
> 3. When a new minor or micro release is made, first create the full
> installation sets, then create patches.
>Besides the data files mentioned above, this also requires access to
> the installation sets of the previous release.
>
> 4. Cleanup of the logging mechanism used by make_installer.pl and its
> modules, so that I can better debug the existing and the new code.
>
>
> Most of the proposed changes have a low impact on the current creation of
> installation sets.  They basically only add new features (collecting
> information about a release, adding it to the VCS,  reading the information
> on next release, checking conditions, creating patches).  However, some
> conditions can be enforced automatically (like using the same uuids for
> components in one release and the next) and that can introduce regressions,
> ie break installation sets.  But I think the danger of that is not bigger
> than with many other new features or bug fixes.  I don't expect conflicts
> with build system changes made or proposed by Jan.
>

Go for it, if you do in trunk, I can merge it into my branches.

I also very little conflict with my build system work, like maybe 1-2
changed makefiles. But thats no serious conflicts, and more me being aware
of the changes.


>
>
> More details about the creation of installation sets and patches can be
> found in the Wiki [2].
>

I really like the idea, that brings us one step closer to a more
installation.

thx for taking this initative.

rgds
jan I.


>
> Regards,
> Andre
>
>
> [1] http://wiki.openoffice.org/**wiki/Building_installation_**
> packages#Conditions_for_**creating_patches
> [2] 
> http://wiki.openoffice.org/**wiki/Building_installation_**packages
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

[proposal] Patches on Windows

Hello everybody,

At the moment we provide full installation sets for every release and
for all platforms and languages. An installation set has a typical size
of roughly 150MB. The size of the actual changes is typically much
smaller. Using patches instead of full installation sets would
considerably reduce the amount of data that has to be downloaded by
users. For new users without existing installation of OpenOffice we
probably still need the full installation sets.

Note that such patches can only be made for minor or micro releases.
Major releases would still be full installation sets.

I have worked in the past months on finding out how our build system has
to be modified in order to create patch sets on Windows. This has
resulted in a set of conditions [1] that have to be fulfilled by the
installation sets. One example of a condition that we currently don't
fulfill is that files must not be deleted in minor or micro releases.

Up to now I have taken two full installation sets and then tweaked the
newer one until I was able to

a) successfully create an .msp patch file and
b) successfully apply it to an OpenOffice that was installed by the
older install set.

I would now like to change the build system, especially the
solenv/bin/make_installer.pl script and its modules, so that the
installation sets it creates can be used without further changes to
create patch sets. I would also like to add the patch creation itself.

For this I propose and seek lazy consensus for the following changes:

1. When a new release is made, create data files that are added to our
version control system (semi automatically) that allow us on the next
release to check and/or enforce the conditions.

2. Before the next release is made, read the data files of the previous
release and check and/or enforce the conditions.

3. When a new minor or micro release is made, first create the full
installation sets, then create patches.
Besides the data files mentioned above, this also requires access to
the installation sets of the previous release.

4. Cleanup of the logging mechanism used by make_installer.pl and its
modules, so that I can better debug the existing and the new code.

Most of the proposed changes have a low impact on the current creation
of installation sets. They basically only add new features (collecting
information about a release, adding it to the VCS, reading the
information on next release, checking conditions, creating patches).
However, some conditions can be enforced automatically (like using the
same uuids for components in one release and the next) and that can
introduce regressions, ie break installation sets. But I think the
danger of that is not bigger than with many other new features or bug
fixes. I don't expect conflicts with build system changes made or
proposed by Jan.

More details about the creation of installation sets and patches can be
found in the Wiki [2].

Regards,
Andre

[1]
http://wiki.openoffice.org/wiki/Building_installation_packages#Conditions_for_creating_patches

[2] http://wiki.openoffice.org/wiki/Building_installation_packages

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Test of VI forum

Hi Phan.

We (infra) are going the move the forum database to a central server, in
order to that we need some preparation work done.

Currently the VI forum is the one with the lowest load (ref. imacat), so we
would like to test the changes on the VI forum, before changing all forums.

The changes itself are done, with only a very short 1-2 minutes
interruption.

We would like you (if possible) to warn the forum users ahead of the
changes, and test the forum imidiatly after the changes.

When would be the earliest point in time, where you could help with test
(takes max. 1 hour) ? please remember I am UTC+2, but I can start early or
go to bed late.

rgds
jan I.

Re: Service Maintenance for pootle and AOO wiki

2013-10-22 Thread imacat

On 2013/10/22 15:42, janI said:
> On 22 October 2013 03:02, imacat  wrote:
>> On 2013/10/22 02:37, janI said:
>>> On 21 October 2013 18:39, Tony Stevenson  wrote:
 Andrea Pescetti wrote on Mon, Oct 21, 2013 at 06:27:50PM +0200:
> Tony Stevenson wrote:
>> Andrea Pescetti wrote on Mon, Oct 21, 2013 at 04:52:14PM +0200:
>>> Imacat (admin) has responded to my question if help is wanted, answer was
>>> that it would be be fine if infra does it (like me) and offered to help.
>>>
>>> If we think along these lines, my plan would be the following:
>>
>> You can ignore me if my help is not needed.  But, still,
> 
> I would never ignore a helping hand, and especially not a qualifed one as
> yours.

Ah...  That is totally unnecessary. ^^;

>>> 1) Thursday evening (16-22 UTC), I wil combine the single forum databases
>>> into the EN database. This will mean short breaks on the single forum,
>>> about 10min each (to copy the tables).
>>>  If time permits, I will convert the FULLTEXT back to MyIsam.
>> That's 0-6 UTC+8 here.  I have works on Friday.  I can stay up to at
>> most 19 UTC (3 UTC+8), but not after that.
> 
> ok, lets do this in another way, please select 2 forums (that have the
> lowest usage) from the db list below:
> 
> | en |
> | es |
> | fr |
> | hu |
> | it |
> | ja |
> | nl |
> | pl |
> | vi |
> | zh |
> ++
> 
> Then I will move tables in these 2 and convert the FULLTEXT tables, as soon
> as I hear from you, and then you can test. Please give me a UTC time, where
> you can test (today/tomorrow), then I do the changes just before that time.

Ah... it's embarrassing that, I will travel to another city later to
deliver an OpenOffice macro class for two days, and will return before
Thursday evening (16-22 UTC). ^^;  That's the earliest time I'm
available this week.

And, currently, VI has the lowest traffic.  But we have to notify
Phan first.

> If it works with these 2 forums, I feel more secure with the rest, and
> maybe Ricardo can do a check on them since he is in the same TZ.
> 
> 
> 
>> And what do you mean by "combining short forum databases into the EN
>> databases"?  So we will only have EN database in the future?
>>
> 
> Yes, and it will problaly be called "forumsaoodb".
> 
> Remark, this is not a problem because all tables (in use) have the naming
> standard:
>  phpbb__
> 
> if you look e.g. in IT, you will see
> | phpbb_it_sessions_keys|
> | phpbb_it_sitelist |
> | phpbb_it_smilies  |
> 
> 
> There are 2 databases I dont understand at the moment:
> 
> | ps_helper  |
> | test   |
> 
> any ideas ?

The "ps_helper" database:

https://www.google.com.tw/#q=ps_helper+mysql

The "test" database can be safely ignored.  It's a standard MySQL
database for testing purpose.  When installing Perl DBD::mysql library,
we need a database to test if DBD::mysql is working.  There should
always a database named "test" (although some DB admins prefer to remove
it), but you do not need to bother with its contents.

> 
> 
>>
>>> 2) Friday morning (8-11 UTC) I will convert tables. This happens online,
>>> and only means slow system while I do it.
>>
>> That is 16-19 UTC+8.  Normally I would be stuck in the traffic going
>> home at this time on Fridays, but I could stay in the office if necessary.
>>
> 
>  see above.
> 
> 
>>> 3) Friday afternoon (15 UTC, depending on pctony), we can take the forums
>>> down for approx 2hours to move the databases.
>>
>> That would be perfect for me.
>>
> it would for me too, but pctony has to go to hospital with his kid, so we
> try to see if we can do it thursday (24/10).
> 
> I would really apriciate your help with the first 2 forums, to make a more
> thorough test. And then hope that ricardo could do a smoke test on the
> others.
> 
> This is of course a service that infra provides so if you want it
> postponed, we will have to find  a way.
> 
> 
>>
>> And also, please add the date (10/24, 10/25).  It's confusing to
>> guess if Friday is 10/25 or 11/1.  (And normally I would bet on 11/1 as
>> 10/25 is very close.)
>>
> 
> Sorry about that, good idea.
> 
> rgds
> jan I.
> 
>>
>>>
>>> In order to finalize the database changes Thursday and move friday, we
>> need
>>> someone with access to all forums to help with the test.
>>>
>>> Could this be an acceptable plan ?  The time is needed, but if preferred
>> I
>>> can do it friday or saturday evening instead (depending on pctony).
>>>
>>> rgds
>>> jan I.
>>>
>>>
>>>
>>>
>>>
 This is now impacting other services and needs to be resolved ASAP,
>> please.

 FWIW the total downtime was 11 minutes.  Which is pretty fast
 considering all the changes that had to be incorporated.


>
> Regards,
>   Andrea.

 --

[Bug 122235] Connection fails with "502 Error reading from remote server"

2013-10-22 Thread Rainer Bielefeld


Hi,

it's really daunting that nobody cares!

CU

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Service Maintenance for pootle and AOO wiki