dev@openoffice.apache.org

[Covert Nelson]

--
Covert Nelson

My Facebook 


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

Completed How the Apache OpenOffice Project Works

[Covert Nelson]

--
Covert Nelson

My Facebook 


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

Donations

[Kylee Bowater]

I wasn't sure where to send this, so sent it to you guys (dev team).

I just tried donating to apache project via paypal and it said that this
recipient cannot currently accept donations. Wasn't sure you were aware.

Best Regards

Kylee

Starting Infrastructure Module

[Covert Nelson]

--
Covert Nelson

My Facebook 


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

Completed Infrastructure Module

[Covert Nelson]

Interesting and informative.
--
Covert Nelson

My Facebook 


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

Re: Donations

[Andrea Pescetti]

Kylee Bowater wrote:

I wasn't sure where to send this, so sent it to you guys (dev team).
I just tried donating to apache project via paypal and it said that this
recipient cannot currently accept donations. Wasn't sure you were aware.


Thank you for reporting, and for trying to donate! This was reported 
yesterday too and the fundraising team (in CC) is informed. I hope that 
the issue can be fixed soon.


Regards,
  Andrea.

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

Re: requirements for vm-admins of forum/translate/wiki

[janI]

On 8 September 2013 00:01, janI  wrote:

>
> On Sep 7, 2013 10:28 PM, "Dave Fisher"  wrote:
> >
> >
> > On Sep 7, 2013, at 2:24 AM, janI wrote:
> >
> > > On 6 September 2013 19:49, Rob Weir  wrote:
> > >
> > >> On Fri, Sep 6, 2013 at 12:14 PM, janI  wrote:
> > >>> On 6 September 2013 15:27, Dave Fisher 
> wrote:
> > >>>
> > 
> >  On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
> > 
> > > On 9/4/13 10:17 PM, Rob Weir wrote:
> > >> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
> > >>> Hi.
> > >>>
> > >>> We have had some longer discussions on different ML/IRC about
> how a
> > >>> vm-admin should behave and which level of service we expect for
> our
> >  servers.
> > >>>
> > >>> We need new admins, so this is also a request for anyone
> interested
> > >> to
> >  chip
> > >>> in.
> > >>>
> > >>> We have had some unfortunate incidents on all 3 vm, of different
> >  nature,
> > >>> which made me question if we as a community:
> > >>
> > >> I assume we have vms for Forums and for Wiki.  But what is the 3rd
> > >> one?
> > >>
> > >>> a) want servers, that are cared for professionally or by
> happening.
> > >>> b) want to (are capable to) maintain the servers ourself.
> > >>> c) are prepared to support a change that make a), b) possible.
> > >>>
> > >>
> > >> I assume we want well-maintained servers that help us get our
> > >> project-related tasks done, and also help serve our users.
> > >
> > > +1 that is the main goal, a working reliable infra structure that
> > >> helps
> > > to run our project.
> > >
> > > In the
> > >> past, before you got involved, we were not very "proactive".  It
> > >> seemed like we just waited for something to break, and then tried
> to
> > >> fix it.
> > >
> > > Exactly and doing it proactive is much better and in the end
> probably
> > > less work.
> > >
> > >>
> > >> I assume another goal is that we have several people helping with
> the
> > >> admin, to share the work, avoid burnouts, cover for vacation, etc.
> > >
> > > And that is a very important goal, we need an environment where we
> can
> > > at any time step in if somebody is not available. I now very well
> in
> > >> the
> > > same way as Jan how it is to be a bottleneck. Well it#s true for
> many
> > > others of us in different areas. But if the servers are not
> running or
> > > the services not available more people are affected faster
> > >
> > >
> > >>
> > >>> I have formulated some thoughts on how admins could work, but in
> >  general I
> > >>> believe we should convince infra to take over the vm
> responsibility
> > >> and
> > >>> keep our well functioning forum/wiki admins.
> > >>>
> > >>> We have a vm-team in place, that was created with the purpose of
> not
> >  having
> > >>> a single person as admin. I my opinion the team have not lived
> up to
> >  that
> > >>> purpose but I am still thankful for the help I have received.
> > >>>
> > >>> Remarks the ideas below are my personal thought, which I have
> used
> >  during
> > >>> the time where I maintained the servers:
> > >>>
> > >>> ===
> > >>> The server should at all times be maintained with the following
> >  priority:
> > >>> 1) security (the backside of being popular is to have the
> attention
> > >> of
> > >>> people who want to gain merit by breaking our servers)
> > >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> > >>> 3) add user wishes (we already have stable systems, 1,2 are far
> > >> more
> > >>> important that enhancing the systems).
> > >>>
> > >>
> > >> and maybe
> > >>
> > >> 3b) Try to evolve systems so users can implement their own
> wishes, in
> > >> a way compatible with 1) and 2).  For example, if routine logos
> and
> > >> footers are synched to resources in the project's SVN tree, then
> any
> > >> committer can update things.
> > 
> >  I really like this idea.
> > 
> > >>>
> > >>> I am impressed, is this real serious ?
> > >>>
> > >>> Think about all the fuzz we have had on several MLs because one
> committer
> > >>> successfully convinced a vm-admin to change our logo, and the
> suggestion
> > >> is
> > >>> to make that automatic.
> > >>>
> > >>> Any committer who wants a change, just do a "svn commit", is that
> really
> > >>> wanted ?
> > >>>
> > >>
> > >> It also makes it possible for any committer to fix a problem if one
> occurs.
> > >>
> > >>> A couple of questions to that:
> > >>>
> > >>> Committer X want extension translate, and do a "svn commit" the
> config is
> > >>> updated, but does not work because of other dependencies, who clears
> up
> > >> the
> > >>> work ? for sure THAT is not a vm-admin task.
> > >>>
> > >>
> > >> Same as when a committer checks 

Re: requirements for vm-admins of forum/translate/wiki

[Rob Weir]

On Sat, Sep 7, 2013 at 5:24 AM, janI  wrote:
> On 6 September 2013 19:49, Rob Weir  wrote:
>
>> On Fri, Sep 6, 2013 at 12:14 PM, janI  wrote:
>> > On 6 September 2013 15:27, Dave Fisher  wrote:
>> >
>> >>
>> >> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
>> >>
>> >> > On 9/4/13 10:17 PM, Rob Weir wrote:
>> >> >> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
>> >> >>> Hi.
>> >> >>>
>> >> >>> We have had some longer discussions on different ML/IRC about how a
>> >> >>> vm-admin should behave and which level of service we expect for our
>> >> servers.
>> >> >>>
>> >> >>> We need new admins, so this is also a request for anyone interested
>> to
>> >> chip
>> >> >>> in.
>> >> >>>
>> >> >>> We have had some unfortunate incidents on all 3 vm, of different
>> >> nature,
>> >> >>> which made me question if we as a community:
>> >> >>
>> >> >> I assume we have vms for Forums and for Wiki.  But what is the 3rd
>> one?
>> >> >>
>> >> >>> a) want servers, that are cared for professionally or by happening.
>> >> >>> b) want to (are capable to) maintain the servers ourself.
>> >> >>> c) are prepared to support a change that make a), b) possible.
>> >> >>>
>> >> >>
>> >> >> I assume we want well-maintained servers that help us get our
>> >> >> project-related tasks done, and also help serve our users.
>> >> >
>> >> > +1 that is the main goal, a working reliable infra structure that
>> helps
>> >> > to run our project.
>> >> >
>> >> > In the
>> >> >> past, before you got involved, we were not very "proactive".  It
>> >> >> seemed like we just waited for something to break, and then tried to
>> >> >> fix it.
>> >> >
>> >> > Exactly and doing it proactive is much better and in the end probably
>> >> > less work.
>> >> >
>> >> >>
>> >> >> I assume another goal is that we have several people helping with the
>> >> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
>> >> >
>> >> > And that is a very important goal, we need an environment where we can
>> >> > at any time step in if somebody is not available. I now very well in
>> the
>> >> > same way as Jan how it is to be a bottleneck. Well it#s true for many
>> >> > others of us in different areas. But if the servers are not running or
>> >> > the services not available more people are affected faster
>> >> >
>> >> >
>> >> >>
>> >> >>> I have formulated some thoughts on how admins could work, but in
>> >> general I
>> >> >>> believe we should convince infra to take over the vm responsibility
>> and
>> >> >>> keep our well functioning forum/wiki admins.
>> >> >>>
>> >> >>> We have a vm-team in place, that was created with the purpose of not
>> >> having
>> >> >>> a single person as admin. I my opinion the team have not lived up to
>> >> that
>> >> >>> purpose but I am still thankful for the help I have received.
>> >> >>>
>> >> >>> Remarks the ideas below are my personal thought, which I have used
>> >> during
>> >> >>> the time where I maintained the servers:
>> >> >>>
>> >> >>> ===
>> >> >>> The server should at all times be maintained with the following
>> >> priority:
>> >> >>> 1) security (the backside of being popular is to have the attention
>> of
>> >> >>> people who want to gain merit by breaking our servers)
>> >> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>> >> >>> 3) add user wishes (we already have stable systems, 1,2 are far
>>  more
>> >> >>> important that enhancing the systems).
>> >> >>>
>> >> >>
>> >> >> and maybe
>> >> >>
>> >> >> 3b) Try to evolve systems so users can implement their own wishes, in
>> >> >> a way compatible with 1) and 2).  For example, if routine logos and
>> >> >> footers are synched to resources in the project's SVN tree, then any
>> >> >> committer can update things.
>> >>
>> >> I really like this idea.
>> >>
>> >
>> > I am impressed, is this real serious ?
>> >
>> > Think about all the fuzz we have had on several MLs because one committer
>> > successfully convinced a vm-admin to change our logo, and the suggestion
>> is
>> > to make that automatic.
>> >
>> > Any committer who wants a change, just do a "svn commit", is that really
>> > wanted ?
>> >
>>
>> It also makes it possible for any committer to fix a problem if one occurs.
>>
>> > A couple of questions to that:
>> >
>> > Committer X want extension translate, and do a "svn commit" the config is
>> > updated, but does not work because of other dependencies, who clears up
>> the
>> > work ? for sure THAT is not a vm-admin task.
>> >
>>
>> Same as when a committer checks in code that breaks the build.
>>
>>
>> > Committer X changes the logo, but doing a "svn commit", Committer Y dont
>> > like it and does a "svn commit", where are our users in this process or
>> our
>> > decision process ?
>> >
>>
>> Same as when a committer checks in code that someone doesn't like.
>>
>> We have a community-based process that handles these things already.
>>
>> Your proposal doesn't really avoid these issues.  It handles it by
>> having an 

bug 107063 (needs update)

[bugreporter99]

Can someone please set the bugs:
26331
20525
as duplicate of:
107063

And change the "Version" of  107063 to 4.0.1.
I tested this on Apache_OpenOffice_4.0.1_Win_x86_install_en-GB.exe on XP and 
this bug still occurs.
(tested with frames of images and tables)
 thx


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

Netbeans created OXT Addon throws an InvalidRegistryException

[Carl Marcum]

Hi all,

I'm working on updating the Netbeans plugin for AOO 4.0.

Installing a Netbeans created OXT Addon throws an InvalidRegistryException:

ImplementationRegistration::registerImplementation()
InvalidRegistryException during registration (prepareRegistry():
source registry is empty)

Any ideas on changes to AOO that may cause this?

I have created a bug for netbeans:
https://issues.apache.org/ooo/show_bug.cgi?id=123215

Thanks,
Carl


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

Reporting a problem with the OpenOffice website

[John Kizer]

Attempt to contribute via paypal failed.

Re: requirements for vm-admins of forum/translate/wiki

[janI]

On 8 September 2013 14:29, Rob Weir  wrote:

> On Sat, Sep 7, 2013 at 5:24 AM, janI  wrote:
> > On 6 September 2013 19:49, Rob Weir  wrote:
> >
> >> On Fri, Sep 6, 2013 at 12:14 PM, janI  wrote:
> >> > On 6 September 2013 15:27, Dave Fisher  wrote:
> >> >
> >> >>
> >> >> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
> >> >>
> >> >> > On 9/4/13 10:17 PM, Rob Weir wrote:
> >> >> >> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
> >> >> >>> Hi.
> >> >> >>>
> >> >> >>> We have had some longer discussions on different ML/IRC about
> how a
> >> >> >>> vm-admin should behave and which level of service we expect for
> our
> >> >> servers.
> >> >> >>>
> >> >> >>> We need new admins, so this is also a request for anyone
> interested
> >> to
> >> >> chip
> >> >> >>> in.
> >> >> >>>
> >> >> >>> We have had some unfortunate incidents on all 3 vm, of different
> >> >> nature,
> >> >> >>> which made me question if we as a community:
> >> >> >>
> >> >> >> I assume we have vms for Forums and for Wiki.  But what is the 3rd
> >> one?
> >> >> >>
> >> >> >>> a) want servers, that are cared for professionally or by
> happening.
> >> >> >>> b) want to (are capable to) maintain the servers ourself.
> >> >> >>> c) are prepared to support a change that make a), b) possible.
> >> >> >>>
> >> >> >>
> >> >> >> I assume we want well-maintained servers that help us get our
> >> >> >> project-related tasks done, and also help serve our users.
> >> >> >
> >> >> > +1 that is the main goal, a working reliable infra structure that
> >> helps
> >> >> > to run our project.
> >> >> >
> >> >> > In the
> >> >> >> past, before you got involved, we were not very "proactive".  It
> >> >> >> seemed like we just waited for something to break, and then tried
> to
> >> >> >> fix it.
> >> >> >
> >> >> > Exactly and doing it proactive is much better and in the end
> probably
> >> >> > less work.
> >> >> >
> >> >> >>
> >> >> >> I assume another goal is that we have several people helping with
> the
> >> >> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
> >> >> >
> >> >> > And that is a very important goal, we need an environment where we
> can
> >> >> > at any time step in if somebody is not available. I now very well
> in
> >> the
> >> >> > same way as Jan how it is to be a bottleneck. Well it#s true for
> many
> >> >> > others of us in different areas. But if the servers are not
> running or
> >> >> > the services not available more people are affected faster
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>> I have formulated some thoughts on how admins could work, but in
> >> >> general I
> >> >> >>> believe we should convince infra to take over the vm
> responsibility
> >> and
> >> >> >>> keep our well functioning forum/wiki admins.
> >> >> >>>
> >> >> >>> We have a vm-team in place, that was created with the purpose of
> not
> >> >> having
> >> >> >>> a single person as admin. I my opinion the team have not lived
> up to
> >> >> that
> >> >> >>> purpose but I am still thankful for the help I have received.
> >> >> >>>
> >> >> >>> Remarks the ideas below are my personal thought, which I have
> used
> >> >> during
> >> >> >>> the time where I maintained the servers:
> >> >> >>>
> >> >> >>> ===
> >> >> >>> The server should at all times be maintained with the following
> >> >> priority:
> >> >> >>> 1) security (the backside of being popular is to have the
> attention
> >> of
> >> >> >>> people who want to gain merit by breaking our servers)
> >> >> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> >> >> >>> 3) add user wishes (we already have stable systems, 1,2 are far
> >>  more
> >> >> >>> important that enhancing the systems).
> >> >> >>>
> >> >> >>
> >> >> >> and maybe
> >> >> >>
> >> >> >> 3b) Try to evolve systems so users can implement their own
> wishes, in
> >> >> >> a way compatible with 1) and 2).  For example, if routine logos
> and
> >> >> >> footers are synched to resources in the project's SVN tree, then
> any
> >> >> >> committer can update things.
> >> >>
> >> >> I really like this idea.
> >> >>
> >> >
> >> > I am impressed, is this real serious ?
> >> >
> >> > Think about all the fuzz we have had on several MLs because one
> committer
> >> > successfully convinced a vm-admin to change our logo, and the
> suggestion
> >> is
> >> > to make that automatic.
> >> >
> >> > Any committer who wants a change, just do a "svn commit", is that
> really
> >> > wanted ?
> >> >
> >>
> >> It also makes it possible for any committer to fix a problem if one
> occurs.
> >>
> >> > A couple of questions to that:
> >> >
> >> > Committer X want extension translate, and do a "svn commit" the
> config is
> >> > updated, but does not work because of other dependencies, who clears
> up
> >> the
> >> > work ? for sure THAT is not a vm-admin task.
> >> >
> >>
> >> Same as when a committer checks in code that breaks the build.
> >>
> >>
> >> > Committer X changes the logo, but doing a "svn commit", Committer Y
> dont

Re: [Request for review] - Solution for 122927 - =IF(AK3=" ";0;IF(AK3="Y";195;IF(AK3="N";125))) produces FALSE instead of $0.00

[Regina Henschel]

Hi Clarence,

I do not understand some part of the description. Questions inline.

Clarence GUO schrieb:

Hi~
I'm working on https://issues.apache.org/ooo/show_bug.cgi?id=122927
I delivered patch to the issue, please help to review.

Root Cause:
In 121126, although in description it only mentioned format code issue,
actually the fix is not only for format code but also for output string for
logic formula cell. The second one introduced this issue.
I think the change for output string change for logic formulas is
reasonable because before 12666


12666 ?

, from 12666's sample file, a cell with

formula "=2>1" will return 1.0.It is very strange. It should return "TRUE"
like that in MS Excel.


In all my OOo versions (from 1.1.5 over 2.4.3 to 3.41 and AOO4.0) =2>1 
returns TRUE. In which version do you see result 1.0 ?



So my fix will based on 12666. The root cause is for logic formula cells,
fix code of 12666 forcibly set output string to true or false. But many AOO
users had manner already that set number format to logic formula cells.
That's different with Excel. In Excel, no matter what number format you set
to logic formula cells, the output strings are always true and false.
In the sample of this issue, users set number format to currency, because
of the forcibly setting, the string changed.

Solution
My solution is to add checking for logic formula cells, if their output
number formats are certain category like number, currency, date, time, etc,
we will not change the output string. but if no certain format categories
were applied, for logic formula cells, will change output string to true
and false.



I have applied your patch and build the source. The resulting AOO still 
shows the error, that FALSE and TRUE cannot be formatted to currency. 
The formatting to other number formats works. The error happens with IF 
with 1 or 2 parameters and with simple comparisons as well.


But it was not a clean build. I will try it with a clean build, but that 
needs half a day on my PC.


Your patch comes with DOS line ends to me. That might be a problem with 
my browser. But it would be nice, if you verify, that your patch has 
UNIX line ends.


Kind regards
Regina






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

IA2 Branch r1519381 IAccessible2 testing - failed Buildbot

[V Stuart Foote]

Steve Y. has merged the AOO TRUNK into the IA2 branch SVN as r1519381.

Anxious to resume QA work on IAccessibile2 implementation.

Unfortunately, while it looks like the IA2 Buildbot job picked up the
change, it is failing with this error:

2 module(s): 
apr
curl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/e/slave14/aoo-w7ia2/build/main/curl
ERROR: error 65280 occurred while making
/cygdrive/e/slave14/aoo-w7ia2/build/ext_libraries/apr

This builbot needs a little TLC.

Stuart



--
View this message in context: 
http://openoffice.2283327.n4.nabble.com/IA2-Branch-r1519381-IAccessible2-testing-failed-Buildbot-tp4652027.html
Sent from the Development mailing list archive at Nabble.com.

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

Re: University Student Promotional Flyer ( was: Re: Yet another flyer)

[Andrea Pescetti]

On 04/09/2013 Drew Jensen wrote:

focus on an Individual university student / teaching aid / professor ...
  PDF
https://docs.google.com/file/d/0Bx7ZNEXlmR0INm5IZzQwQXRodGM
ODT
https://docs.google.com/file/d/0Bx7ZNEXlmR0IVmJ3QzVDNjQyaHc


It's a very nice improvement over the existing leaflet. And a good idea 
to have a few different types of leaflet (all as PDF and ODT) ready to 
use for different targets.



I tried to put this on confluence BTW, but am having problems logging on


What kind of problems? If you used your old @openoffice.org account for 
the cwiki, you must ask infrastruct...@apache.org to change your e-mail 
address. Symptom: if you login, you cannot access content (not even read 
the pages available to unauthenticated visitors, let alone edit them).



So - If someone wants to move it to the cwiki, please do


Can you suggest a specific page that your leaflets should be attached to?

Regards,
  Andrea.

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

Re: Has anyone tried AOO with Windows 8.1 Preview?

[Rob Weir]

On Fri, Sep 6, 2013 at 3:29 PM, Rob Weir  wrote:
> The ISOs for Win 8.1 are available here:
>
> http://windows.microsoft.com/en-us/windows-8/preview-iso
>
> I'm wondering if anyone has tried AOO 4.0 with it yet?  If there are
> any new critical issues there it would be good to know and possibly
> fix in 4.0.1.
>

I installed the 8.1 Preview on a VM, 64-bit, US English.   It seems to
work fine.  I didn't do an in-depth test, but did load each of the
apps and tried a few things.

Released date for Windows 8.1 is October 17th.  So this will be after
AOO 4.0.1, but before AOO 4.1.

Has any date been set for the new Mac OS yet?

-Rob

> -Rob

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

Re: [Request for review] - Solution for 122927 - =IF(AK3=" ";0;IF(AK3="Y";195;IF(AK3="N";125))) produces FALSE instead of $0.00

[Regina Henschel]

Hi Clarence,

an additional remark: You should not use rFormatter before you are sure 
it exists. Keep "if (&rFormatter==NULL)" at the beginning.


Kind regards
Regina

Clarence GUO schrieb:

Hi~
I'm working on https://issues.apache.org/ooo/show_bug.cgi?id=122927
I delivered patch to the issue, please help to review.

Root Cause:
In 121126, although in description it only mentioned format code issue,
actually the fix is not only for format code but also for output string for
logic formula cell. The second one introduced this issue.
I think the change for output string change for logic formulas is
reasonable because before 12666, from 12666's sample file, a cell with
formula "=2>1" will return 1.0. It is very strange. It should return "TRUE"
like that in MS Excel.
So my fix will based on 12666. The root cause is for logic formula cells,
fix code of 12666 forcibly set output string to true or false. But many AOO
users had manner already that set number format to logic formula cells.
That's different with Excel. In Excel, no matter what number format you set
to logic formula cells, the output strings are always true and false.
In the sample of this issue, users set number format to currency, because
of the forcibly setting, the string changed.

Solution
My solution is to add checking for logic formula cells, if their output
number formats are certain category like number, currency, date, time, etc,
we will not change the output string. but if no certain format categories
were applied, for logic formula cells, will change output string to true
and false.




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

Does our "Decision Making" information need additional instructions?

[Kay Schenk]

The information we currently have on Decision Making can be found in our
Orientation section:

http://openoffice.apache.org/orientation/decision-making.html

On that page, there are explanations for types of decision making used in
this project specifically and within the Apache Software Foundation. In my
opinion, this is very good "how to" guide, but somewhat limited as a "when
to" guide.

Most of the source code changes done currently are preceded by a BZ issue.
This is wonderfully simple and anyone on the commits list can follow what
and why something has been done.  In other cases, for much larger changes,
discussions have been initiated. So, we would NOT see an action such as
deleting an entire module undertaken without discussion. Decision making
for these types of change follow a a well-known and followed process.

Aside from code changes, there are changes to other areas of the project --
web sites, wiki, forums -- whose changes are not typically noted in BZ.
Sometimes there are proposals and discussions, sometimes not.  These are
the kinds of changes that may need additional clarification with regard to
decision making.

In summary, what kinds of change for non-source code need  a
[PROPOSAL]/discussion before change?



-
MzK

"Truth is stranger than fiction, but it is because Fiction is obliged
 to stick to possibilities. Truth isn't."
 -- "Following the Equator", Mark Twain

Re: Problem with PayPal donations to the Apache Software Foundation

[Daniel Shahaf]

On Sat, Sep 07, 2013 at 10:47:20AM +0200, Andrea Pescetti wrote:
> To the Apache fundraisers: a user (see below for context) reported a
> problem with PayPal donations to the Apache Software Foundation
> account, used for Apache OpenOffice donations.
> 
> Indeed the button at
> 
> http://www.apache.org/foundation/contributing.html#Paypal
> 
> leads to the following error message:

Thanks for the report.  We're looking into the issue and updated the website
to note it.  We hope it will be fixed in a few days so it would be great if
you could retry the donation then.  Thanks for your interest in the ASF!

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

Re: bug 107063 (needs update)

[Kay Schenk]

On Sun, Sep 8, 2013 at 6:55 AM,  wrote:

> Can someone please set the bugs:
> 26331
> 20525
> as duplicate of:
> 107063
>
> And change the "Version" of  107063 to 4.0.1.
> I tested this on Apache_OpenOffice_4.0.1_Win_x86_install_en-GB.exe on XP
> and this bug still occurs.
> (tested with frames of images and tables)
>  thx
>

I marked the duplicate issues you suggested. Please log in and update the
version on your own if you would. If there is some problem you can't do
this, please let us know.

Thanks.


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


-- 
-
MzK

"Truth is stranger than fiction, but it is because Fiction is obliged
 to stick to possibilities. Truth isn't."
 -- "Following the Equator", Mark Twain

Re: requirements for vm-admins of forum/translate/wiki

[Andrea Pescetti]

On 04/09/2013 Rob Weir wrote:

On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
I assume we want well-maintained servers that help us get our
project-related tasks done, and also help serve our users.


Yes we do. And Jan's proposal seems very reasonable and dictated from 
experience (both personal experience and the experience of actually 
maintaining these servers).



some thoughts on how admins could work, but in general I
believe we should convince infra to take over the vm responsibility and
keep our well functioning forum/wiki admins.


Last time we approached Infra on this, their answer was: find resources 
(people) within the OpenOffice project to take care of the non-standard 
tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe 
they helped a bit respecting these lines so far.


Handing over to Infra would indeed be "peace of mind" for us, but I 
still think that your proposal makes sense in light of the above: Infra 
prefers that project-specific tools are maintained by the project itself 
as a first/primary contact, and escalate to Infra if needed.


By the way, if you believe that Infra could now be available to support 
us more closely, feel free to investigate.



maybe
3b) Try to evolve systems so users can implement their own wishes, in
a way compatible with 1) and 2).  For example, if routine logos and
footers are synched to resources in the project's SVN tree, then any
committer can update things.


This is not feasible in the current state. Even ignoring the fact that 
this issue derailed the discussion, I see no benefit in implementing 
this: if we have a real (reasonable active) team maintaining the 
servers, and the team is not a bottleneck for the community, we will be 
fine with it. I won't feel "excluded" if I have to ask someone to change 
some configuration: this routinely happens for Infra-maintained 
services, or for our Bugzilla, and it works.



A good setup would be, 3 types of admin:
Each server will have an appointed "owner" (anchor-admin)
A number of persons have full sudo on a server (admin)
A number of persons can reboot/restart/work on po files (help-admin)


Something that we might discuss (but I guess this is implicit in your 
proposal) is to avoid that the same person is the "anchor-admin" (or 
"contact-admin", i.e., the first point of contact) for all the three 
machines. This might help in sharing the knowledge and mitigate the 
"loneliness" you have experienced so far in maintaining our infrastructure.


It would actually make a lot of sense that you continue to be the 
"main/anchor-admin" for at least one of the machines, so that the other 
machines can be smoothly transitioned and that the whole knowledge, not 
only what's written in the documentation, can be shared.


Regards,
  Andrea.

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

Re: requirements for vm-admins of forum/translate/wiki

[Rob Weir]

On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti  wrote:
> On 04/09/2013 Rob Weir wrote:
>>
>> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
>>
>> I assume we want well-maintained servers that help us get our
>> project-related tasks done, and also help serve our users.
>
>
> Yes we do. And Jan's proposal seems very reasonable and dictated from
> experience (both personal experience and the experience of actually
> maintaining these servers).
>
>
>>> some thoughts on how admins could work, but in general I
>>> believe we should convince infra to take over the vm responsibility and
>>> keep our well functioning forum/wiki admins.
>
>
> Last time we approached Infra on this, their answer was: find resources
> (people) within the OpenOffice project to take care of the non-standard
> tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they
> helped a bit respecting these lines so far.
>
> Handing over to Infra would indeed be "peace of mind" for us, but I still
> think that your proposal makes sense in light of the above: Infra prefers
> that project-specific tools are maintained by the project itself as a
> first/primary contact, and escalate to Infra if needed.
>
> By the way, if you believe that Infra could now be available to support us
> more closely, feel free to investigate.
>
>
>> maybe
>> 3b) Try to evolve systems so users can implement their own wishes, in
>> a way compatible with 1) and 2).  For example, if routine logos and
>> footers are synched to resources in the project's SVN tree, then any
>> committer can update things.
>
>
> This is not feasible in the current state. Even ignoring the fact that this
> issue derailed the discussion, I see no benefit in implementing this: if we
> have a real (reasonable active) team maintaining the servers, and the team
> is not a bottleneck for the community, we will be fine with it. I won't feel
> "excluded" if I have to ask someone to change some configuration: this
> routinely happens for Infra-maintained services, or for our Bugzilla, and it
> works.
>

That does not match my experience at all.  From trying to get the
terms and conditions statement on the Forum to integrating Google
Analytic across the websites to rolling out the new logo, my
experience has been that getting simple content changes make to the
VMs has been very frustrating.  Some of these changes took months.

(Note:  I'm not talking about "configuration".  I'm talking about
website content, things like logos, contact information, terms and
conditions, copyright statements, etc.)

You say that if we had active admin teams maintaining the servers,
this would be easier.  But we don't have such a team  So these changes
have been painful.  Considering the admins are scarce and their time
is precious, I'd like to find ways that we can allow some degree of
"self- service" for committers, so we don't waste admin time on
trivial content changes.  Have the admins focus on things that only
they can do.

So this is not an either/or question.  We should both have an active
admin team as well as move toward allowing committers to maintain the
content of our websites.

Regards,

-Rob

>
>>> A good setup would be, 3 types of admin:
>>> Each server will have an appointed "owner" (anchor-admin)
>>> A number of persons have full sudo on a server (admin)
>>> A number of persons can reboot/restart/work on po files (help-admin)
>
>
> Something that we might discuss (but I guess this is implicit in your
> proposal) is to avoid that the same person is the "anchor-admin" (or
> "contact-admin", i.e., the first point of contact) for all the three
> machines. This might help in sharing the knowledge and mitigate the
> "loneliness" you have experienced so far in maintaining our infrastructure.
>
> It would actually make a lot of sense that you continue to be the
> "main/anchor-admin" for at least one of the machines, so that the other
> machines can be smoothly transitioned and that the whole knowledge, not only
> what's written in the documentation, can be shared.
>
> Regards,
>   Andrea.
>
>
> -
> 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: requirements for vm-admins of forum/translate/wiki

[janI]

On 8 September 2013 23:40, Andrea Pescetti  wrote:

> On 04/09/2013 Rob Weir wrote:
>
>> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
>>
>> I assume we want well-maintained servers that help us get our
>> project-related tasks done, and also help serve our users.
>>
>
> Yes we do. And Jan's proposal seems very reasonable and dictated from
> experience (both personal experience and the experience of actually
> maintaining these servers).
>
>
>  some thoughts on how admins could work, but in general I
>>> believe we should convince infra to take over the vm responsibility and
>>> keep our well functioning forum/wiki admins.
>>>
>>
> Last time we approached Infra on this, their answer was: find resources
> (people) within the OpenOffice project to take care of the non-standard
> tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they
> helped a bit respecting these lines so far.
>
> Handing over to Infra would indeed be "peace of mind" for us, but I still
> think that your proposal makes sense in light of the above: Infra prefers
> that project-specific tools are maintained by the project itself as a
> first/primary contact, and escalate to Infra if needed.
>
> By the way, if you believe that Infra could now be available to support us
> more closely, feel free to investigate.
>
>
>  maybe
>> 3b) Try to evolve systems so users can implement their own wishes, in
>> a way compatible with 1) and 2).  For example, if routine logos and
>> footers are synched to resources in the project's SVN tree, then any
>> committer can update things.
>>
>
> This is not feasible in the current state. Even ignoring the fact that
> this issue derailed the discussion, I see no benefit in implementing this:
> if we have a real (reasonable active) team maintaining the servers, and the
> team is not a bottleneck for the community, we will be fine with it. I
> won't feel "excluded" if I have to ask someone to change some
> configuration: this routinely happens for Infra-maintained services, or for
> our Bugzilla, and it works.
>
>
>  A good setup would be, 3 types of admin:
>>> Each server will have an appointed "owner" (anchor-admin)
>>> A number of persons have full sudo on a server (admin)
>>> A number of persons can reboot/restart/work on po files (help-admin)
>>>
>>
> Something that we might discuss (but I guess this is implicit in your
> proposal) is to avoid that the same person is the "anchor-admin" (or
> "contact-admin", i.e., the first point of contact) for all the three
> machines. This might help in sharing the knowledge and mitigate the
> "loneliness" you have experienced so far in maintaining our infrastructure.
>

just a short clarification, when I wrote this proposal, my intention was to
offer being "anchor-admin" for all 3 vms for a shorter period, and hope one
of the admins would like to more involved, so that person could in due time
take over some or all of the vms. My experience with the vm-team is that it
will be hard enough to find active admins.

It would actually make a lot of sense that you continue to be the
> "main/anchor-admin" for at least one of the machines, so that the other
> machines can be smoothly transitioned and that the whole knowledge, not
> only what's written in the documentation, can be shared.
>

Since I wrote this proposal a lot of things have happened and with the
current environment, this is a challenge I am not ready for.

I think this discussion is valuable and once consensus is reached, I will
(like hopefully the rest of the vm-team) take a closer look and see if it
fits with what I believe in.

rgds
jan I.

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

Re: Does our "Decision Making" information need additional instructions?

[Rob Weir]

On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk  wrote:
> The information we currently have on Decision Making can be found in our
> Orientation section:
>
> http://openoffice.apache.org/orientation/decision-making.html
>
> On that page, there are explanations for types of decision making used in
> this project specifically and within the Apache Software Foundation. In my
> opinion, this is very good "how to" guide, but somewhat limited as a "when
> to" guide.
>

I drafted the orientation pages based on my understanding.   I didn't
get many comments at the time, so I'm sure there is room for
improvement.

> Most of the source code changes done currently are preceded by a BZ issue.
> This is wonderfully simple and anyone on the commits list can follow what
> and why something has been done.  In other cases, for much larger changes,
> discussions have been initiated. So, we would NOT see an action such as
> deleting an entire module undertaken without discussion. Decision making
> for these types of change follow a a well-known and followed process.
>
> Aside from code changes, there are changes to other areas of the project --
> web sites, wiki, forums -- whose changes are not typically noted in BZ.
> Sometimes there are proposals and discussions, sometimes not.  These are
> the kinds of changes that may need additional clarification with regard to
> decision making.
>
> In summary, what kinds of change for non-source code need  a
> [PROPOSAL]/discussion before change?
>

For source changes and non-source changes the idea is essentially the
same.  It is a judgement call more than a hard rule.  That's why we
should try to vote in committers who have demonstrated good judgement
as well as technical skills.

We operate in Commit-Then-Review mode most of the time, except when
close to a Release Candidate.  We try to avoid unnecessary discussion.
 A timid committer who needs to review every minor change with is an
annoyance to most of the 453 subscribers of the dev list.  So we want
to encourage JFDI where appropriate.  But it is still a judgement
call.

But in general, I think (my personal view) a committer should put out
a proposal in situations such as:

1) They are unsure of the technical merits of what they want to do.
They want an extra pair of eyes to review the proposal point out
weaknesses, alternatives, etc.

2) It is a job for more than one person or requires coordination
across several subgroups within the project.  By putting out a formal
proposal you can find additional volunteers and move forward in a
coordinated way.

3)  A change to one of our websites that impacts terms and conditions,
license, copyright, branding, etc.  So not a technical change, but a
substantive change to content in these areas.  These require PMC
review.

4) A technical change that breaks backwards compatibility of the product.

5) Changes that break things.  Sometimes this is unavoidable.  But it
should be proposed and coordinated like #2 above.

6) Changes that cannot easily be reversed.  Code changes and most
website changes are in SVN and can be reverted.  But some changes,
like administrative bulk actions in BZ, cannot be easily undone.

7) Public statements in behalf of the project, e.g., some blog posts
and announcements, press releases, etc.

Those are examples, but the list is by no means complete.  And for
almost any of these there may be cases where CTR or even JFDI is
appropriate.   I'd take them more as "things to think about" when
developing good judgement.

Regards,

-Rob

>
>
> -
> MzK
>
> "Truth is stranger than fiction, but it is because Fiction is obliged
>  to stick to possibilities. Truth isn't."
>  -- "Following the Equator", Mark Twain

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

Re: requirements for vm-admins of forum/translate/wiki

[Daniel Shahaf]

Rob Weir wrote on Sun, Sep 08, 2013 at 18:11:19 -0400:
> On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti  wrote:
> > On 04/09/2013 Rob Weir wrote:
> >>
> >> On Wed, Sep 4, 2013 at 12:36 PM, janI  wrote:
> >>
> >> I assume we want well-maintained servers that help us get our
> >> project-related tasks done, and also help serve our users.
> >
> >
> > Yes we do. And Jan's proposal seems very reasonable and dictated from
> > experience (both personal experience and the experience of actually
> > maintaining these servers).
> >
> >
> >>> some thoughts on how admins could work, but in general I
> >>> believe we should convince infra to take over the vm responsibility and
> >>> keep our well functioning forum/wiki admins.
> >
> >
> > Last time we approached Infra on this, their answer was: find resources
> > (people) within the OpenOffice project to take care of the non-standard
> > tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they
> > helped a bit respecting these lines so far.
> >
> > Handing over to Infra would indeed be "peace of mind" for us, but I still
> > think that your proposal makes sense in light of the above: Infra prefers
> > that project-specific tools are maintained by the project itself as a
> > first/primary contact, and escalate to Infra if needed.
> >
> > By the way, if you believe that Infra could now be available to support us
> > more closely, feel free to investigate.
> >
> >
> >> maybe
> >> 3b) Try to evolve systems so users can implement their own wishes, in
> >> a way compatible with 1) and 2).  For example, if routine logos and
> >> footers are synched to resources in the project's SVN tree, then any
> >> committer can update things.
> >
> >
> > This is not feasible in the current state. Even ignoring the fact that this
> > issue derailed the discussion, I see no benefit in implementing this: if we
> > have a real (reasonable active) team maintaining the servers, and the team
> > is not a bottleneck for the community, we will be fine with it. I won't feel
> > "excluded" if I have to ask someone to change some configuration: this
> > routinely happens for Infra-maintained services, or for our Bugzilla, and it
> > works.
> >
> 
> That does not match my experience at all.  From trying to get the
> terms and conditions statement on the Forum to integrating Google
> Analytic across the websites to rolling out the new logo, my
> experience has been that getting simple content changes make to the
> VMs has been very frustrating.  Some of these changes took months.
> 
> (Note:  I'm not talking about "configuration".  I'm talking about
> website content, things like logos, contact information, terms and
> conditions, copyright statements, etc.)
> 
> You say that if we had active admin teams maintaining the servers,
> this would be easier.  But we don't have such a team  So these changes
> have been painful.  Considering the admins are scarce and their time
> is precious, I'd like to find ways that we can allow some degree of
> "self- service" for committers, so we don't waste admin time on
> trivial content changes.  Have the admins focus on things that only
> they can do.
> 

I'd also like to point out that allowing any committer to make changes
--- when that is easy to implement, does not raise security or privacy
issues, and does not lead to abuse --- makes the project more
inclusionary, which is a good thing.

It's not unlike enabling non-committers to review patches.

Daniel

> So this is not an either/or question.  We should both have an active
> admin team as well as move toward allowing committers to maintain the
> content of our websites.
> 
> Regards,
> 
> -Rob
> 
> >
> >>> A good setup would be, 3 types of admin:
> >>> Each server will have an appointed "owner" (anchor-admin)
> >>> A number of persons have full sudo on a server (admin)
> >>> A number of persons can reboot/restart/work on po files (help-admin)
> >
> >
> > Something that we might discuss (but I guess this is implicit in your
> > proposal) is to avoid that the same person is the "anchor-admin" (or
> > "contact-admin", i.e., the first point of contact) for all the three
> > machines. This might help in sharing the knowledge and mitigate the
> > "loneliness" you have experienced so far in maintaining our infrastructure.
> >
> > It would actually make a lot of sense that you continue to be the
> > "main/anchor-admin" for at least one of the machines, so that the other
> > machines can be smoothly transitioned and that the whole knowledge, not only
> > what's written in the documentation, can be shared.
> >
> > Regards,
> >   Andrea.
> >
> >
> > -
> > 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 additi

Open office

[Al]

I used Open Office for some time before I was contacted and informed that my
trial period was up and I had a choice of several payment options to
continue the use.  I see no where in all your advertising that this is
brought to the subscribers attention while you are urging them to use Open
Office.  

This is a very underhanded stunt as you well know; to allow users to build
huge information units and then tell them to pay or go somewhere else, thus
having to move and try to save all their information.

Your song and dance is a very convincing act until the final curtain when
you must pay to get out of the theatre.
Al Banks
alanbank...@gmail.com 

Re: Open office

[Graham Lauder]

Al,

There is no trial period for OpenOffice and you definitely don't have to
pay for it.
Simply ensure that you only download from the official download site
http://www.openoffice.org
Any other site is most likely to be scam.

Cheers
GL


On Mon, Sep 9, 2013 at 10:32 AM, Al  wrote:

>I used Open Office for some time before I was contacted and informed
> that my trial period was up and I had a choice of several payment options
> to continue the use.  I see no where in all your advertising that this is
> brought to the subscribers attention while you are urging them to use Open
> Office.
>
> This is a very underhanded stunt as you well know; to allow users to build
> huge information units and then tell them to pay or go somewhere else, thus
> having to move and try to save all their information.
>
> Your song and dance is a very convincing act until the final curtain when
> you must pay to get out of the theatre.
> Al Banks
> alanbank...@gmail.com
>

Re: Open office

[Rob Weir]

On Sun, Sep 8, 2013 at 6:32 PM, Al  wrote:

>I used Open Office for some time before I was contacted and informed
> that my trial period was up and I had a choice of several payment options
> to continue the use.  I see no where in all your advertising that this is
> brought to the subscribers attention while you are urging them to use Open
> Office.
>
>


Hello Al,

Apache OpenOffice is free.  No charge.  No subscription.  No renewal fee.
No trial period.  You download it and use it, forever.

The Apache Software Foundation is a non-profit organization.  We never sell
software.  Our charitable mission is to make open source software available
to the public for free.  That's what we do.

You might want to review the following blog post on some of the scams out
there:

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

If you happen to remember where you downloaded your copy of OpenOffice from
(it was not from us) please share it with us at
priv...@openoffice.apache.org.

And you are welcome to download the latest version of OpenOffice directly
from us at http://www.openoffice.org/download.

You are right to be upset, but trust me when I say that this was not us.

Regards,

Rob Weir, Apache OpenOffice Project Management Committee


This is a very underhanded stunt as you well know; to allow users to build
> huge information units and then tell them to pay or go somewhere else, thus
> having to move and try to save all their information.
>
> Your song and dance is a very convincing act until the final curtain when
> you must pay to get out of the theatre.
> Al Banks
> alanbank...@gmail.com
>

Reporting a problem with the OpenOffice website

[Mel Goddard]

GET OUT OF MY COMPUTER!
I DIDN'T ASK FOR YOU, I DON'T NEED YOU, AND YOU ARE INTERFERING WITH MY WORK 
ON THIS THING!

GET OUT NOW!
mdgoddard3...@i-zoom.net 



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

[PROPOSAL] Admin mailing list

[Rob Weir]

I'd like to propose a new mailing list:  ad...@openoffice.apache.org

It would serve a few primary purposes:

1) A focused mailing list to help our volunteer admins coordinate
maintenance of our project infrastructure, or at least that portion of
it maintained by the project.

2) It would give a single point of contact for admin-related
questions, outage reports and requests from project members or the
public.

3) It would allow other parties interested in monitoring our admin
discussion, say Infra@ members, to follow a more focused list.

If this idea sounds good, we'd need the usual set of 3 or so
moderators, geographically disbursed.

Regards,

-Rob

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

Re: [Request for review] - Solution for 122927 - =IF(AK3=" ";0;IF(AK3="Y";195;IF(AK3="N";125))) produces FALSE instead of $0.00

[Clarence GUO]

Regina,
Sorry for my pen mistake, all statement of 12666 in my previous comment
should be 121126. I also corrected it in the issue.
About formula "=2>1", it is from the sample XLS in 121126. Once I rolled
back fix code of 121126, I found it returned 1.0.
I tested formula with "=2>1" which applied currency number format, it works.
Thanks for you reminder, I will add checking "if (&rFormatter==NULL)"

Clarence




2013/9/9 Regina Henschel 

> Hi Clarence,
>
> I do not understand some part of the description. Questions inline.
>
> Clarence GUO schrieb:
>
>  Hi~
>> I'm working on 
>> https://issues.apache.org/ooo/**show_bug.cgi?id=122927
>> I delivered patch to the issue, please help to review.
>>
>> Root Cause:
>> In 121126, although in description it only mentioned format code issue,
>> actually the fix is not only for format code but also for output string
>> for
>> logic formula cell. The second one introduced this issue.
>> I think the change for output string change for logic formulas is
>> reasonable because before 12666
>>
>
> 12666 ?
>
>
> , from 12666's sample file, a cell with
>
>> formula "=2>1" will return 1.0.It is very strange. It should return
>> "TRUE"
>>
>> like that in MS Excel.
>>
>
> In all my OOo versions (from 1.1.5 over 2.4.3 to 3.41 and AOO4.0) =2>1
> returns TRUE. In which version do you see result 1.0 ?
>
>
>  So my fix will based on 12666. The root cause is for logic formula cells,
>> fix code of 12666 forcibly set output string to true or false. But many
>> AOO
>> users had manner already that set number format to logic formula cells.
>> That's different with Excel. In Excel, no matter what number format you
>> set
>> to logic formula cells, the output strings are always true and false.
>> In the sample of this issue, users set number format to currency, because
>> of the forcibly setting, the string changed.
>>
>> Solution
>> My solution is to add checking for logic formula cells, if their output
>> number formats are certain category like number, currency, date, time,
>> etc,
>> we will not change the output string. but if no certain format categories
>> were applied, for logic formula cells, will change output string to true
>> and false.
>>
>>
> I have applied your patch and build the source. The resulting AOO still
> shows the error, that FALSE and TRUE cannot be formatted to currency. The
> formatting to other number formats works. The error happens with IF with 1
> or 2 parameters and with simple comparisons as well.
>
> But it was not a clean build. I will try it with a clean build, but that
> needs half a day on my PC.
>
> Your patch comes with DOS line ends to me. That might be a problem with my
> browser. But it would be nice, if you verify, that your patch has UNIX line
> ends.
>
> Kind regards
> Regina
>
>
>
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [PROPOSAL] Admin mailing list

[Rob Weir]

On Sep 8, 2013, at 10:06 PM, Daniel Shahaf  wrote:

> Rob Weir wrote on Sun, Sep 08, 2013 at 21:42:17 -0400:
>> I'd like to propose a new mailing list:  ad...@openoffice.apache.org
>
> Public archives or private archives?

I was assuming it would be public.  If something needed to be
discussed privately it could be done on the infra or infra-dev lists.

Does that make sense?  Or would you recommend something else?

-Rob




>
>> It would serve a few primary purposes:
>>
>> 1) A focused mailing list to help our volunteer admins coordinate
>> maintenance of our project infrastructure, or at least that portion of
>> it maintained by the project.
>>
>> 2) It would give a single point of contact for admin-related
>> questions, outage reports and requests from project members or the
>> public.
>>
>> 3) It would allow other parties interested in monitoring our admin
>> discussion, say Infra@ members, to follow a more focused list.

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

Re: [PROPOSAL] Admin mailing list

[Daniel Shahaf]

Rob Weir wrote on Sun, Sep 08, 2013 at 21:42:17 -0400:
> I'd like to propose a new mailing list:  ad...@openoffice.apache.org
> 

Public archives or private archives?

> It would serve a few primary purposes:
> 
> 1) A focused mailing list to help our volunteer admins coordinate
> maintenance of our project infrastructure, or at least that portion of
> it maintained by the project.
> 
> 2) It would give a single point of contact for admin-related
> questions, outage reports and requests from project members or the
> public.
> 
> 3) It would allow other parties interested in monitoring our admin
> discussion, say Infra@ members, to follow a more focused list.

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

Re: [PROPOSAL] Admin mailing list

[Peter Junge]

Seems quite reasonable

Peter

Rob Weir  wrote:
>I'd like to propose a new mailing list:  ad...@openoffice.apache.org
>
>It would serve a few primary purposes:
>
>1) A focused mailing list to help our volunteer admins coordinate
>maintenance of our project infrastructure, or at least that portion of
>it maintained by the project.
>
>2) It would give a single point of contact for admin-related
>questions, outage reports and requests from project members or the
>public.
>
>3) It would allow other parties interested in monitoring our admin
>discussion, say Infra@ members, to follow a more focused list.
>
>If this idea sounds good, we'd need the usual set of 3 or so
>moderators, geographically disbursed.
>
>Regards,
>
>-Rob
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [PROPOSAL] Admin mailing list

[Daniel Shahaf]

Rob Weir wrote on Sun, Sep 08, 2013 at 22:14:13 -0400:
> On Sep 8, 2013, at 10:06 PM, Daniel Shahaf  wrote:
> 
> > Rob Weir wrote on Sun, Sep 08, 2013 at 21:42:17 -0400:
> >> I'd like to propose a new mailing list:  ad...@openoffice.apache.org
> >
> > Public archives or private archives?
> 
> I was assuming it would be public.  If something needed to be
> discussed privately it could be done on the infra or infra-dev lists.

infra-dev@ is public.

infra@ is technically private but allows any committer to subscribe,
which makes it wider than is suitable for some discussions (such as "Who
is going to install that security patch that has just been announced?").

> Does that make sense?  Or would you recommend something else?

Hard to say: some topics should be public and some topics need to be
private, but I don't know what topics you guys are looking for a place
to discuss, so I can't say whether a private list or a public list would
better meet your needs.

HTH

Daniel

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

Re: [PROPOSAL] Admin mailing list

[janI]

On Sep 9, 2013 6:17 AM, "Daniel Shahaf"  wrote:
>
> Rob Weir wrote on Sun, Sep 08, 2013 at 22:14:13 -0400:
> > On Sep 8, 2013, at 10:06 PM, Daniel Shahaf  wrote:
> >
> > > Rob Weir wrote on Sun, Sep 08, 2013 at 21:42:17 -0400:
> > >> I'd like to propose a new mailing list:  ad...@openoffice.apache.org
> > >
> > > Public archives or private archives?
> >
> > I was assuming it would be public.  If something needed to be
> > discussed privately it could be done on the infra or infra-dev lists.
>
> infra-dev@ is public.
>
> infra@ is technically private but allows any committer to subscribe,
> which makes it wider than is suitable for some discussions (such as "Who
> is going to install that security patch that has just been announced?").
>
> > Does that make sense?  Or would you recommend something else?
>
> Hard to say: some topics should be public and some topics need to be
> private, but I don't know what topics you guys are looking for a place
> to discuss, so I can't say whether a private list or a public list would
> better meet your needs.

I have nothing against such a list, but it was not needed while I
coordinated vm-team. I prefer direct mail for that purpose.

I am the opinion that such a request should come from the admins, if wanted.

rgds
jan I

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

Re: bug 107063 (needs update)

[Herbert Duerr]

On 08.09.2013 23:38, Kay Schenk wrote:

On Sun, Sep 8, 2013 at 6:55 AM,  wrote:


Can someone please set the bugs:
26331
20525
as duplicate of:
107063

And change the "Version" of  107063 to 4.0.1.
I tested this on Apache_OpenOffice_4.0.1_Win_x86_install_en-GB.exe on XP
and this bug still occurs.
(tested with frames of images and tables)


Thanks for checking this issue with our latest snapshot! Knowing that a 
bug is still there is an important data point.



I marked the duplicate issues you suggested. Please log in and update the
version on your own if you would. If there is some problem you can't do
this, please let us know.


For re-confirming issues such as 107063 we have the field "latest 
confirmation on". The version field itself should record when a bug 
first appeared.


Also we there is no release of AOO 4.0.1 yet, there are only snapshots 
on the way to 4.0.1 that use "4.0.1" in various strings for technical 
reasons. So recording a bug against a pre-release should only be against 
e.g. AOO401-dev but not against the target version.


Herbert

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