date:20120621

On 6/21/12 7:56 AM, Chao Huang wrote:
 All the fixed are included in R1352129. You can use the build after
 R1352129.
 
 What's the revision of the latest build on buildbot?

for developers I recommend to subscribe to the ooo-commits mailing list.
Here you can see all commits (on the webpage, the code repository) and
will also see status mails from the build bots.

These mails contains further info about the build. See for example
http://ci.apache.org/builders/aoo-win7/builds/205 of the Win7 build bot
which failed last night.

Further useful links regarding the build bots

- http://ci.apache.org/projects/openoffice/install/ - where you can
find the final builds

- http://ci.apache.org/projects/openoffice/rat-output.html - the RAT
tool report

- http://ci.apache.org/projects/openoffice/buildlogs/ - build bot logs

Juergen

 
 
 2012/6/21 Zhe Liu aliu...@gmail.com
 
 Do the builds on buildbot have these code changes include?
 If yes, I will try compare it with my last testing.

 2012/6/21 Chao Huang chao.de...@gmail.com:
 The thrid batch for memory leak issue has been delivered yet. Thanks for
 Aim's review.

 https://issues.apache.org/ooo/show_bug.cgi?id=120038
 https://issues.apache.org/ooo/show_bug.cgi?id=120040

 Propose to put these memory leak fixed into 3.4.1


 2012/6/20 Chao Huang chao.de...@gmail.com

 The second batch for memory leak issue has been delivered yet. Thanks
 for
 Herbert and JianFang's review.

 http://goog_371113529
 https://issues.apache.org/ooo/show_bug.cgi?id=120019
 https://issues.apache.org/ooo/show_bug.cgi?id=120021
 https://issues.apache.org/ooo/show_bug.cgi?id=120028



 2012/6/15 Chao Huang chao.de...@gmail.com

 hi, all

 I'm Huang Chao from China. My interesting areas are Mac porting,
 performance(startup, loading, saving, etc), stability, build env.
 At recent stage, I will focus on memory leak issue in Aoo3.4.

 Here are the fixed for memory leak defects I opened. Please confirm
 them
 and review them. I will continue to work on this area. Thanks!

 https://issues.apache.org/ooo/show_bug.cgi?id=119991
 https://issues.apache.org/ooo/show_bug.cgi?id=119992
 https://issues.apache.org/ooo/show_bug.cgi?id=119996
 https://issues.apache.org/ooo/show_bug.cgi?id=119997

 Please note that the patches for bug119996 and bug119997 are on the
 same
 source file.

 --
 Best regards,
 Chao Huang




 --
 Best regards,
 Chao Huang




 --
 Best regards,
 Chao Huang



 --
 Best Regards
 From aliu...@gmail.com

Re: 3.4.1_release_blocker requested: [Bug 120045] Format case change crashes OOo

On 6/21/12 8:02 AM, De Bin Lei wrote:
 Got it. so it is a crash and regression one.
 +1 for 3.4.1 release blocker from my view, thx.

+1, I will set the release blocker flag for 3.4.1.

Debin, Will you merge it in the AOO340 branch?

Juergen

 
 2012/6/21 Ji Yan yanji...@gmail.com
 
 DeBin,

  Yes, it's a regression issue. The problem doesn't exist in OO 3.3

 2012/6/21 De Bin Lei debin@gmail.com

 Hi, Ji
 Is it a regression one?

 2012/6/21 Yan Ji yanji...@gmail.com

 I propose bug 120045[1] as 3.4.1 release blocker.  AOO crashed easily
 while trying to lowercase a word which contains uppercase in Mac OS.

 [1] https://issues.apache.org/ooo/show_bug.cgi?id=120045

 Thanks  Best Regards, Yan Ji

 Begin forwarded message:

 From: bugzi...@apache.org
 Subject: 3.4.1_release_blocker requested: [Bug 120045] Format case
 change crashes OOo
 Date: June 21, 2012 11:31:50 AM GMT+08:00
 To: ooo-iss...@incubator.apache.org
 Reply-To: ooo-iss...@incubator.apache.org

 Yan Ji yanji...@gmail.com has asked  for 3.4.1_release_blocker:
 Bug 120045: Format case change crashes OOo
 https://issues.apache.org/ooo/show_bug.cgi?id=120045


 --- Additional Comments from Yan Ji yanji...@gmail.com
 The problem happened to Mac platform when changing to lower case with
 word
 contains upper case characters. It's obviously serious problem.

 Propose 3.4.1 release blocker




 --
 Best regards
 Lei De Bin




 --


 Thanks  Best Regards, Yan Ji

Re: 3.4.1_release_blocker requested: [Bug 120045] Format case change crashes OOo

2012-06-21 Thread De Bin Lei

2012/6/21 Jürgen Schmidt jogischm...@googlemail.com

 On 6/21/12 8:02 AM, De Bin Lei wrote:
  Got it. so it is a crash and regression one.
  +1 for 3.4.1 release blocker from my view, thx.

 +1, I will set the release blocker flag for 3.4.1.

 Debin, Will you merge it in the AOO340 branch?


Yes, I will. However, there is no fix for it. Anyway I will take care of
the code check in for 3.4.1 branch.


 Juergen

 
  2012/6/21 Ji Yan yanji...@gmail.com
 
  DeBin,
 
   Yes, it's a regression issue. The problem doesn't exist in OO 3.3
 
  2012/6/21 De Bin Lei debin@gmail.com
 
  Hi, Ji
  Is it a regression one?
 
  2012/6/21 Yan Ji yanji...@gmail.com
 
  I propose bug 120045[1] as 3.4.1 release blocker.  AOO crashed easily
  while trying to lowercase a word which contains uppercase in Mac OS.
 
  [1] https://issues.apache.org/ooo/show_bug.cgi?id=120045
 
  Thanks  Best Regards, Yan Ji
 
  Begin forwarded message:
 
  From: bugzi...@apache.org
  Subject: 3.4.1_release_blocker requested: [Bug 120045] Format case
  change crashes OOo
  Date: June 21, 2012 11:31:50 AM GMT+08:00
  To: ooo-iss...@incubator.apache.org
  Reply-To: ooo-iss...@incubator.apache.org
 
  Yan Ji yanji...@gmail.com has asked  for 3.4.1_release_blocker:
  Bug 120045: Format case change crashes OOo
  https://issues.apache.org/ooo/show_bug.cgi?id=120045
 
 
  --- Additional Comments from Yan Ji yanji...@gmail.com
  The problem happened to Mac platform when changing to lower case with
  word
  contains upper case characters. It's obviously serious problem.
 
  Propose 3.4.1 release blocker
 
 
 
 
  --
  Best regards
  Lei De Bin
 
 
 
 
  --
 
 
  Thanks  Best Regards, Yan Ji
 
 
 
 





-- 
Best regards
Lei De Bin

Commit message summaries


Date: Wed Jun 20 06:58:35 2012
Was [Re: svn commit: r1351948 - 
/incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx]



New Revision: 1351948

URL: http://svn.apache.org/viewvc?rev=1351948view=rev
Log:
for #119951#


Recently there have been three commits with great fixes but with the 
problem that the log message was way too short: In my opinion just 
mentioning the issue number in the commit message makes following the 
progress of code unnecessarily difficult. I suggest to provide at least 
a rough idea on why something was changed in the summary, e.g.

  #i119951# fix the animation effect of a shape when it has been grouped
would have been much better IMHO.

Not having a self-sustaining commit message reduces the quality of the 
repository. Adding a bit of redundancy also prevents that a typo such as 
transposed digits makes it almost impossible to understand why a change 
was done.


I also suggest to mention the issue tracker when referring to an issue 
number. In the history of the OOo project there were already three 
different bug-trackers were used. E.g. issuetracker that has been 
migrated to our bugzilla instance was referred to by the 'i' before the 
bug number such as #i123456#. Other projects in our ecosystem use 
similar conventions such as #fdo12345#. If we want to be good citizens 
in this ecosystem then we should not be egocentric by working as if 
there are no other trackers and there never have been other trackers.


What do others think?

Herbert

Re: Fwd: [CONF] Apache OpenOffice Community Localization Plan

2012-06-21 Thread Andrea Pescetti

CCing Martin and Robert, since I'm not sure they are on this list. I'll 
also leave relevant messages below, for context.


In short: 3.4.0 has already been released without Slovenian, but 
Slovenian will be included in 3.4.1 (end of July) and intermediate 
builds will be available as soon as next week, follow

https://cwiki.apache.org/OOOUSERS/aoo-34-unofficial-developer-snapshots.html
for the builds and
https://issues.apache.org/ooo/show_bug.cgi?id=120036
for the integration.

Regards,
  Andrea.

On 20/06/2012 Jürgen Schmidt wrote:

On 6/20/12 10:28 AM, Jürgen Schmidt wrote:

On 6/16/12 5:34 PM, Martin Srebotnjak wrote:

So, there will not be a Slovenian 3.4 build?



in short, yes ;-)


Ok I have added Slovenian on the pootle server. It looks good, 100%
complete (ui + help). Perfect, I will include it in the build asap.

Info:
I was able to add Slovenian so fast because the language is already
supported on the Pootle server and I could simply add it to the projects.

This is not the case for many other languages but we I am working
together with infra on it.

Juergen



Juergen



Lp, m.

2012/6/4 Martin Srebotnjakmi...@filmsi.net:

Will the Slovenian 3.4 release be built?

Thanks, m.


2012/6/2 Martin Srebotnjakmi...@filmsi.net


Yes, of course, it is available under the new Apache 2 license.

We are also localizing LibreOffice under its own licence.

Lp, m.


2012/6/2 Andrea Pescettipesce...@apache.org


On 01/06/2012 Martin Srebotnjak wrote:


here is the full Slovenian translation for Apache OpenOffice 3.4:
http://ooo.siccla.net/gsi/apacheOO/3.4.0/GSI_sl.sdf.gz



Thanks Martin, Robert, it's great to see that you are continuing the
OpenOffice localization effort! I assume your updates are available under
the Apache 2 license (the current OpenOffice license), right?

You might consider to submit an ICLA http://www.apache.org/licenses/#clas
: you still retain the copyright but it helps the project to have a proper
intellectual property tracking, and to give you direct commit rights for
future updates if helpful.

Regards,
  Andrea.

Re: Apache OpenOffice Business Partnership Inquiry

2012-06-21 Thread fa...@filepuma.com

Hi dear Sir,

Glad to receive your reply, and thanks for your corrections.

We have corrected the content you have mentioned, including the publishier, 
name and so on. About the License,  we are going to divide Freeware into 
Freeware and Open source in detail. 

Thanks for your time. If you have any other inquiry, please feel free to 
contact us. Have a nice day!

Best wishes,

Faith
fa...@filepuma.com
Filepuma.com

2012-06-21 



fa...@filepuma.com 



From:  Rob Weir 
Date:  2012-06-20  23:31:00 
To:  ooo-dev; fa...@filepuma.com 
Cc:  
Subject:  Re: OpenOffice.org Business Partnership Inquiry 
  
On Wed, Jun 20, 2012 at 3:10 AM, fa...@filepuma.com fa...@filepuma.com wrote:
 Hi OpenOffice.org Webmaster,

 I'm sorry to bother you.
 I am Faith from Filepuma.com. I write to you just to consult whether we can 
 have a potential chance to cooperate with you. And recently we have updated 
 your product at our site that you can have a visit.

Hello Faith,
I see the listing here:
http://www.filepuma.com/download/openoffice.org_3.4-767/
Is that the right listing?  If so, I'd like to suggest some corrections:
1) The name of the product is Apache OpenOffice, not OpenOffice.org.
 (This is a new change, starting with the 3.4 release.
2)  The license is Apache License 2.0.  It is not freeware.  Does
your website make that distinction, between freeware and open source?
 Strictly speaking, freeware is only a statement about the initial
cost, that the software is available for free download.  But many
freeware products ask for payment, either after a period of time, or
to unlock advanced features.   Open source software does not do that.
It is free to use, copy, redistribute, etc.  Open source software also
comes with the source code of the application, allowing programmers to
study, modify and enhance the application.  Freeware does not.
3) The publisher should be Apache Software Foundation, not
OpenOffice.org.  This is also a new change starting with our 3.4
release.
 Filepuma.com is a website for providing the simplest method of downloading 
 the newest versions of the best software, and we are not focusing on quantity 
 but quality. To make your downloads as fast as possible, we provide very fast 
 servers with 100Mb connections.

 You are really a great tool and OpenOffice.org enjoys great reputation among 
 users. We're very interested in becoming the mirror for OpenOffice.org 
 download. I'm sure our partnership can guarantee you great advantages. We can 
 do a few things to promote your program like newsletter mentions and 
 front-page exposure.

 If you have any other ideas we are very open and happy to discuss them on 
 becoming OpenOffice.org's mirror download link. What we want to have is a 
 win-win relationship that benefits us both. We strongly think that business 
 cooperation between you and us will be a wise decision, and both of us can 
 have more triumphs.

If you want to host a copy of the Apache OpenOffice installer on your
website, then no further permission is required.  Redistribution is
permitted by the license.
If you want to be a mirror operator for Apache releases, then more
information can be found here:
http://www.apache.org/info/how-to-mirror.html
If you have further questions, please cc the ooo-dev@incubator.apache.org list.
Regards,
-Rob
 Looking forward to receiving your feedback very much. Thanks for your time.

 P.S. If answering mails like this one is not among your daily tasks, please 
 forward it to the appropriate executive. Thanks again.

 Best regards,

 Faith Lee
 fa...@filepuma.com
 Filepuma.com

Re: Commit message summaries


Hi,

On 21.06.2012 08:36, Herbert Duerr wrote:

Date: Wed Jun 20 06:58:35 2012

Was [Re: svn commit: r1351948 -
/incubator/ooo/trunk/main/sd/source/core/CustomAnimationEffect.cxx]


New Revision: 1351948

URL: http://svn.apache.org/viewvc?rev=1351948view=rev
Log:
for #119951#


Recently there have been three commits with great fixes but with the problem
that the log message was way too short: In my opinion just mentioning the issue
number in the commit message makes following the progress of code unnecessarily
difficult. I suggest to provide at least a rough idea on why something was
changed in the summary, e.g.
#i119951# fix the animation effect of a shape when it has been grouped
would have been much better IMHO.



I agree here.


Not having a self-sustaining commit message reduces the quality of the
repository. Adding a bit of redundancy also prevents that a typo such as
transposed digits makes it almost impossible to understand why a change was 
done.



That is right. I had made a couple of these typos in the past and additional 
existing text help in these cases a lot.



I also suggest to mention the issue tracker when referring to an issue number.
In the history of the OOo project there were already three different
bug-trackers were used. E.g. issuetracker that has been migrated to our
bugzilla instance was referred to by the 'i' before the bug number such as
#i123456#. Other projects in our ecosystem use similar conventions such as
#fdo12345#. If we want to be good citizens in this ecosystem then we should not
be egocentric by working as if there are no other trackers and there never have
been other trackers.

What do others think?



As AOO Bugzilla is our intrinsic issue database, I am in favor to mark issue 
numbers from this issue database without any further letters, e.g. #119951#.
In case it is needed to reference other issue databases an identification of 
these other issue databases makes sense from my point of view.


Best regards, Oliver.

Re: [RELEASE][3.4.1]Release Bloker: proposing Bug 119803 - After upgrading to 3.4 RTF User Fields are not saving

On 6/21/12 3:45 AM, YangTerry wrote:
 
 Re-send it, seems failed last time.
 
 This is a bug about user fields lost after save in RTF file.
 This is a regression issue, it is work fine in OOo 3.3.
 ej19...@gmail.com
   2012-06-07 10:23:13 UTC
 To duplicate:
 Create a rtf document with a version  3.4.  
 Menu Options
 Insert
 -Field
 --Other
 ---User Fields

 At this point the variable list is shown.

 Insert a new variable and click the green check.

 The variable shows up in the list and appears to be saving.

 Insert the variable into the document to use it.

 Close the doc and reopen.  

 When the document reopens the variable is not present and is de-referenced 
 in the doc.

 This appears to be a critical error.  This function is used by many 
 developers along with UNO to published merged documents.

 Resolution:  Downgrade OpenOffice to 3.4.


+1 if it's a regression than it's fine for me. Who will take care of
this issue?

Juergen

Re: Commit message summaries

2012-06-21 Thread Wang Zhe

Sure, I agree with Herbert. We need some basic and rough comment for the
code change, then others could review it much easier.
2012/6/21 Oliver-Rainer Wittmann orwittm...@googlemail.com

Hi,

On 21.06.2012 08:36, Herbert Duerr wrote:

Date: Wed Jun 20 06:58:35 2012

Was [Re: svn commit: r1351948 -
/incubator/ooo/trunk/main/sd/**source/core/**CustomAnimationEffect.cxx]

New Revision: 1351948

URL:
http://svn.apache.org/viewvc?**rev=1351948view=revhttp://svn.apache.org/viewvc?rev=1351948view=rev
Log:
for #119951#

Recently there have been three commits with great fixes but with the
problem
that the log message was way too short: In my opinion just mentioning the
issue
number in the commit message makes following the progress of code
unnecessarily
difficult. I suggest to provide at least a rough idea on why something was
changed in the summary, e.g.
#i119951# fix the animation effect of a shape when it has been grouped
would have been much better IMHO.

I agree here.

Not having a self-sustaining commit message reduces the quality of the
repository. Adding a bit of redundancy also prevents that a typo such as
transposed digits makes it almost impossible to understand why a change
was done.

That is right. I had made a couple of these typos in the past and
additional existing text help in these cases a lot.

I also suggest to mention the issue tracker when referring to an issue
number.
In the history of the OOo project there were already three different
bug-trackers were used. E.g. issuetracker that has been migrated to our
bugzilla instance was referred to by the 'i' before the bug number such as
#i123456#. Other projects in our ecosystem use similar conventions such as
#fdo12345#. If we want to be good citizens in this ecosystem then we
should not
be egocentric by working as if there are no other trackers and there
never have
been other trackers.

What do others think?

As AOO Bugzilla is our intrinsic issue database, I am in favor to mark
issue numbers from this issue database without any further letters, e.g.
#119951#.
In case it is needed to reference other issue databases an identification
of these other issue databases makes sense from my point of view.

Best regards, Oliver.

Re: Commit message summaries

On 6/21/12 9:39 AM, Wang Zhe wrote:
Sure, I agree with Herbert. We need some basic and rough comment for the
code change, then others could review it much easier.
2012/6/21 Oliver-Rainer Wittmann orwittm...@googlemail.com

We have already introduced the Patch by, Review By .. fields for adding
further information.

How about logs like

issuenumber: issue subject line

fix: short description/summary

(on demand only)
Patch By:
Suggest By:
Found by:
Reviewed By:

A common notation used by all would be of course helpful

Juergen

Hi,

On 21.06.2012 08:36, Herbert Duerr wrote:

Date: Wed Jun 20 06:58:35 2012

Was [Re: svn commit: r1351948 -
/incubator/ooo/trunk/main/sd/**source/core/**CustomAnimationEffect.cxx]

New Revision: 1351948

URL:
http://svn.apache.org/viewvc?**rev=1351948view=revhttp://svn.apache.org/viewvc?rev=1351948view=rev
Log:
for #119951#

I agree here.

That is right. I had made a couple of these typos in the past and
additional existing text help in these cases a lot.

What do others think?

Best regards, Oliver.

Re: [Call-for-Review] one fix for odt saving performance improvement

On 6/21/12 7:06 AM, li zhang wrote:
 for more information, you can refer to the below link:
 
 http://wiki.services.openoffice.org/wiki/ODT_saving_performance_improvement
 
 On Thu, Jun 21, 2012 at 1:00 PM, li zhang lizh@gmail.com wrote:
 
 hi, all
 I'm zhang li from China. My main focus is performance(loading, saving,
 asynchronous loading, etc).

 I have one fix need for review. It is about odt saving. Please check the
 below for details, thanks!

 https://issues.apache.org/ooo/show_bug.cgi?id=120030

 root cause:
 Do profiling on a sample file, SfxObjectShell::GenerateAndStoreThumbnail
 is to be found occypy too much time, and it will call SwFlyFrm::Paint
 several times, but it's unnecessary to paint thumbnail so many times when
 saving.

 solution:
 When thumbnail is generated and stored, in SwFlyFrm::Paint, current
 visible rectangle will be compared with fly frame rectangle, if the two
 rectangles don't intersect, SwFlyFrm::Paint will return, need no repaint.

 

I will take care of this

Juergen

Can't find sample file in some resolved defects

2012-06-21 Thread Li Feng Wang

Hello,
 I am trying to verify some resovled defects, But there are some defects
make me hard to start.
 like  *Bug 117708*
https://issues.apache.org/ooo/show_bug.cgi?id=117708 - Assertion
cannot retrieve default status indicator
  found in CAT0 test case tFileSaveeAll in w_updt.bas

  there is no link or other way to find this bas file. or maybe there is
case storage I don't know.

  By the way, I suggest to add link if sample file not in attachment.

-- 
Best Wishes, LiFeng Wang

[Call-for-Review] Bug 120049 (Aoo crash when modify the Random effects animation effect's trigger condition to Start effect on click of )

2012-06-21 Thread tanmgeng

Hi all,
The fix for bug 120049 is ready.
Here is the link: 
https://issues.apache.org/ooo/show_bug.cgi?id=120049
Anybody who could help to review it?
Thanks.

2012-06-21 



tanmgeng

[Call-For-Review] Bug 119592 [From Symphony] The left-style columns display with the same width when opening with AOO

2012-06-21 Thread Jinlong Wu

Hello,

I have a fix for bug 119592 (
https://issues.apache.org/ooo/show_bug.cgi?id=119592).

Can anyone help to review it?

Thank you!

Re: Question about text clipping mechanism in word processor

2012-06-21 Thread Fan Zheng

Hi, All:

Let me talk about my concern.

Regarding the value is correct, there may exist the formatting mechanism
difference.

1. MS Word consider the above-paragraph-spacing  + line-spacing (may also
including the below-paragraph-spacing? not sure) as the available vertical
space for containing text;
2. OpenOffice consider the ling-spacing only as the available vertical
space for containing text;

Is that correct? If yes, then the inner value of line-spacing inside
SvxLineSpacingItem should actually equal to the value
of above-paragraph-spacing  + line-spacing stored in DOC files;
And in my opinion, such modification should be in filter but not in
formatting;

A further question is: as the total vertical space include above, line and
below are actually available for containing text, why MS Word trying to
distinguish them? On some other words, what the exact meaning of above and
below paragraph spacing in MS word?

And following the tips from Oliver, such value should only works on the
first line of paragraph. So whether it means that, the
above-paragraph-spacing has some kind of difference definition to the UL
space inside OpenOffice?



2012/6/20 Joost Andrae joost.and...@gmx.de

 Hi,

 Am 20.06.2012 13:43, schrieb ZuoJun Chen:

  Hi, Fan

  I have extracted parameter from first paragraph in sample file

 1 Spacing before paragraph 18pt in doc file
 2 above-paragraph-spacing  in SvxULSpaceItem: 360
 3 line-spacing of said para in doc file: 12pt
 4 line-spacing of said para in SvxLineSpacingItem:240

 Seems that the value mapping works, Looking forward to your further
 response:)


 soffice internally uses twips and msoffice uses pt

 https://en.wikipedia.org/wiki/**Twip https://en.wikipedia.org/wiki/Twip

 Above values are correct.

 Kind regards, Joost

Re: Can't find sample file in some resolved defects


Hello Feng Wang,

On 21.06.2012 10:51, Li Feng Wang wrote:

  I am trying to verify some resovled defects, But there are some defects
make me hard to start.
  like  *Bug 117708*
https://issues.apache.org/ooo/show_bug.cgi?id=117708  - Assertion
cannot retrieve default status indicator
   found in CAT0 test case tFileSaveeAll in w_updt.bas

   there is no link or other way to find this bas file. or maybe there is
case storage I don't know.


Other than the revision history I know nothing about this but I saw that 
in issue #i117363# that the test scriot w_updt.bas has been splitted 
into two
https://svn.apache.org/repos/asf/incubator/ooo/trunk/main/testautomation 
 /writer/required/w_updt_1.bas


https://svn.apache.org/repos/asf/incubator/ooo/trunk/main/testautomation/writer/required/w_updt_2.bas
for performance reasons.

Hope that helps,
Herbert

Re: Commit message summaries

2012-06-21 Thread Thorsten Behrens

Herbert Duerr wrote:
 I also suggest to mention the issue tracker when referring to an
 issue number. In the history of the OOo project there were already
 three different bug-trackers were used. E.g. issuetracker that has
 been migrated to our bugzilla instance was referred to by the 'i'
 before the bug number such as #i123456#. Other projects in our
 ecosystem use similar conventions such as #fdo12345#. If we want to
 be good citizens in this ecosystem then we should not be egocentric
 by working as if there are no other trackers and there never have
 been other trackers.
 
Hi Herbert,

yes, I think that would be helpful. There's no pre-Apache history in
svn itself, but the code is full of 'i#12345', '#123456' etc.
references - deviating from that scheme in commit messages appears
needlessly confusing.

Cheers,

-- Thorsten


pgpp7mNczGjbA.pgp
Description: PGP signature

Re: Question about text clipping mechanism in word processor


Hi,

On 21.06.2012 11:23, Fan Zheng wrote:

Hi, All:

Let me talk about my concern.

Regarding the value is correct, there may exist the formatting mechanism
difference.

1. MS Word consider the above-paragraph-spacing  + line-spacing (may also
including the below-paragraph-spacing? not sure) as the available vertical
space for containing text;


My investigation of MS word 2003 and 2010 reveals the following:
- the additional space of above-paragraph-spacing for rendering the text of the 
first text line.
- the below-paragraph-spacing from the previous paragraph is _not_ used for 
rendering the text of the first text line.
- for the character background and the paragraph background the 
above-paragraph-spacing is _not_ used. Thus, it looks very funny in MS Word 
2003/2010 when the additional space is used for the characters, but not for the 
different backgrounds.
- for object positioning the above-paragraph-spacing is used. Thus, an object 
whose vertical position is 0cm to the top of the line also looks funny from my 
point of view.


My conclusion here is that MS Word is doing really inconsistent and funny 
things.


2. OpenOffice consider the ling-spacing only as the available vertical
space for containing text;

Is that correct? If yes, then the inner value of line-spacing inside
SvxLineSpacingItem should actually equal to the value
of above-paragraph-spacing  + line-spacing stored in DOC files;
And in my opinion, such modification should be in filter but not in
formatting;



Yes, for your question.
But I disagree regarding adjusting the value of the SvxLineSpacingItem:
(1) We have no SvxLineSpacingItem for the first line and the rest of the text 
lines. Such a features also does not exist in ODF. From my point of view such a 
feature does not make sense.
(2) The above-paragaph-spacing belongs to the corresponding Svx...Item which 
represent the paragraphh margins.
(3) MS Word is doing really inconsistent and funny things here. I am proposing 
_not_ to reflect these in our document model.



A further question is: as the total vertical space include above, line and
below are actually available for containing text, why MS Word trying to
distinguish them? On some other words, what the exact meaning of above and
below paragraph spacing in MS word?



As I am not the expert of MS Word and its file format I can not answer these 
questions. From my point of view only MS experts can answer them.



And following the tips from Oliver, such value should only works on the
first line of paragraph. So whether it means that, the
above-paragraph-spacing has some kind of difference definition to the UL
space inside OpenOffice?



Here, I am not sure, if I am getting the point.

Best regards, Oliver.

Re: [DISCUSS]What is the criteria for 3.4.1 release blocker?

2012-06-21 Thread Shenfeng Liu

I wonder if any one can help to update this criteria to 3.4.1 wiki ?
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Feature+Planning
It was my favorite, but I'm on vacation now and difficult to update the wiki 
from my phone...

- Simon


发自我的 iPhone

在 2012-6-21，7:54，De Bin Lei le...@apache.org 写道：

 Juergen, thank for your comments, now the criteria is more clear, thanks
 again.
 
 2012/6/21 Jürgen Schmidt jogischm...@googlemail.com
 
 On 6/21/12 5:51 AM, Dennis E. Hamilton wrote:
 I think safety is of high value.
 
 That includes security issues and also data loss/corruption.  The last
 includes crashers that result in unrecoverable loss of work.  Hidden loss
 of work and document corruption that does not appear until the document is
 opened later is particularly serious.
 
 
 
 We used in general the following criteria (details where we are more
 less based on can be foud under [2])
 
 - crashes (including data loss/corruption)
 - security fixes
 - regressions
 
 I would also include
 - memory leaks
 when a fix is available and it is well tested that nothing else breaks
 
 
 - maintenance issues (like updating reference type library, version
 strings, images, ...)
 
 
 A micro release like 3.4.1 is only for fixing serious problems and not
 to introduce new features. Excepting new translations.
 
 Minor releases, eg. 3.5, can include any kind of fix, features and
 improvements. Bigger UI changes should be discussed and probably better
 included in a major release.
 
 See also [1] and especially [2]
 
 We should update these pages on demand to reflect our guideline how we
 want handle this in the future. A common understanding is of course
 important here.
 
 
 Juergen
 
 
 [1] http://wiki.services.openoffice.org/wiki/Release_criteria
 [2] http://wiki.services.openoffice.org/wiki/Stopper
 
 
 - Dennis
 
 -Original Message-
 From: dongjun zong [mailto:zongdj...@gmail.com]
 Sent: Wednesday, June 20, 2012 20:31
 To: ooo-dev@incubator.apache.org
 Subject: Re: [DISCUSS]What is the criteria for 3.4.1 release blocker?
 
 I think high severity regression issue, common usage function related
 issue
 should be considered as release blocker.
 
 2012/6/21 Ji Yan yanji...@gmail.com
 
 From my point of view, security and high usability issue should be set
 as
 blocker
 
 2012/6/21 debin lei le...@apache.org
 
 Hi, All
 I noticed that there are some issues, which are proposed as 3.4.1
 release
 blocker recently. However, I am not sure what is the criteria for the
 release blocker?
 Is it regression or impact serious ? Or high benefit to risk ratio from
 dev
 view ?
 I think maybe consider more things, but not sure.
 So if you can give your criteria and discuss here to make the things
 more
 clear will be very helpful.
 Thanks.
 
 Best regards.
 Lei De Bin
 
 
 
 
 --
 
 
 Thanks  Best Regards, Yan Ji
 
 
 
 --
 Best regards
 Lei De Bin

Re: Commit message summaries


Extending my older mail with some statistical details.
On 21.06.2012 11:47, I wrote:

I'm also against using a bare issue number, because having a number that
can be reliably parsed by eventual tools (e.g. a tool that updates
bugzilla with the revision number, a tool that links the revision commit
to the corresponding bug URL, etc.) is no extra effort whereas it opens
a whole world of opportunities. I prefer that computers do such work
that can be automated because they are rather good at that.


There are more good reason for my suggestion to continue with the 
i-decorated issue number:


The code base of AOO 3.4.0 already has more than 8000(!!!) code comments 
using the #i123456# convention for referencing issues in bugzilla.


There are more than 20 changeset comments in the OOo code history 
which also use this convention. What other than confusion would we gain 
if we abandoned this convention and why should we as the continuation of 
the OpenOffice.org project do that?


Interestingly there are about 9000 code comments using the undecorated 
issue number for references to the pre-OOo bug tracking system. 
Reintroducing undecorated issue numbers again for new commits only adds 
uncalled-for confusion. Speaking of the pre-OOo bug tracker system I 
think in our code base we should remove the references into it. The 
pre-OOo tracker died many years ago and that devalued these references.


Herbert

Re: [DISCUSS]What is the criteria for 3.4.1 release blocker?

On 6/21/12 12:40 PM, Shenfeng Liu wrote:
 I wonder if any one can help to update this criteria to 3.4.1 wiki ?

I am not sure what you mean, do you mean to add a link on the wiki page
to the definition of showstopper?


 https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Feature+Planning

 by the way I moved this page under Releases - AOO 3.4.1 but the link
still works

The idea was to reduce the redundant version number in each page name,
see
https://cwiki.apache.org/confluence/display/OOOUSERS/Unofficial+Developer+Snapshots

But as I have noticed afterwards it doesn't really work because the page
itself is under OOOUSERS directly. I thought it would be saved
hierarchical as in mediawiki :-(


 It was my favorite, but I'm on vacation now and difficult to update the wiki 
 from my phone...

enjoy your vacation

Juergen

 
 - Simon
 
 
 发自我的 iPhone
 
 在 2012-6-21，7:54，De Bin Lei le...@apache.org 写道：
 
 Juergen, thank for your comments, now the criteria is more clear, thanks
 again.

 2012/6/21 Jürgen Schmidt jogischm...@googlemail.com

 On 6/21/12 5:51 AM, Dennis E. Hamilton wrote:
 I think safety is of high value.

 That includes security issues and also data loss/corruption.  The last
 includes crashers that result in unrecoverable loss of work.  Hidden loss
 of work and document corruption that does not appear until the document is
 opened later is particularly serious.



 We used in general the following criteria (details where we are more
 less based on can be foud under [2])

 - crashes (including data loss/corruption)
 - security fixes
 - regressions

 I would also include
 - memory leaks
 when a fix is available and it is well tested that nothing else breaks


 - maintenance issues (like updating reference type library, version
 strings, images, ...)


 A micro release like 3.4.1 is only for fixing serious problems and not
 to introduce new features. Excepting new translations.

 Minor releases, eg. 3.5, can include any kind of fix, features and
 improvements. Bigger UI changes should be discussed and probably better
 included in a major release.

 See also [1] and especially [2]

 We should update these pages on demand to reflect our guideline how we
 want handle this in the future. A common understanding is of course
 important here.


 Juergen


 [1] http://wiki.services.openoffice.org/wiki/Release_criteria
 [2] http://wiki.services.openoffice.org/wiki/Stopper


 - Dennis

 -Original Message-
 From: dongjun zong [mailto:zongdj...@gmail.com]
 Sent: Wednesday, June 20, 2012 20:31
 To: ooo-dev@incubator.apache.org
 Subject: Re: [DISCUSS]What is the criteria for 3.4.1 release blocker?

 I think high severity regression issue, common usage function related
 issue
 should be considered as release blocker.

 2012/6/21 Ji Yan yanji...@gmail.com

 From my point of view, security and high usability issue should be set
 as
 blocker

 2012/6/21 debin lei le...@apache.org

 Hi, All
 I noticed that there are some issues, which are proposed as 3.4.1
 release
 blocker recently. However, I am not sure what is the criteria for the
 release blocker?
 Is it regression or impact serious ? Or high benefit to risk ratio from
 dev
 view ?
 I think maybe consider more things, but not sure.
 So if you can give your criteria and discuss here to make the things
 more
 clear will be very helpful.
 Thanks.

 Best regards.
 Lei De Bin




 --


 Thanks  Best Regards, Yan Ji



 --
 Best regards
 Lei De Bin

Re: Commit message summaries

On 6/21/12 11:47 AM, Herbert Duerr wrote:
 On 21.06.2012 10:17, Jürgen Schmidt wrote:
 We have already introduced the Patch by, Review By .. fields for adding
 further information.

 How about logs like

 
 issuenumber:issue subject line
 
 I agree that the issue subject line is better than nothing, but I prefer
 that the subject line is about why the change was made. See e.g. the six
 different changes for issue 118923. Why would anyone want the same
 change header for each commit when you can have a description instead
 that matches the change much better?

good point and I agree.

That means we use something like

###
issuenumber + 1_line_summary/description

longer description_on_demand

patch_by_on_demand
...
###

where

issuenumber is

- either the plain number + :
- or #number#
- or #inumber#

I can live with all but we should agree on one notation. My preference
is the first and then the second. I don't think we need the lower case
'i' anymore.

Older commit messages can be interpreted by knowing the older
conventions and today we have only one bugtracker.

Issues from other bugtracker systems should be ideally duplicated in our
system. The other systems can be public or private bug tracking systems
and issue numbers of the latter ones don't help anybody.

I would like to hear other opinions of people who actually work with our
code.

Juergen

 
 I'm also against using a bare issue number, because having a number that
 can be reliably parsed by eventual tools (e.g. a tool that updates
 bugzilla with the revision number, a tool that links the revision commit
 to the corresponding bug URL, etc.) is no extra effort whereas it opens
 a whole world of opportunities. I prefer that computers do such work
 that can be automated because they are rather good at that.
 
 fix:short description/summary
 
 I like the commit conventions used in the linux kernel. Browse some
 commit links of the kernel shortlog at
 
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog
 to see some examples.
 
 A common notation used by all would be of course helpful
 
 +1
 
 Herbert

Re: [VCLAuto] Problems with build.xml

2012-06-21 Thread Reizinger Zoltán


2012.06.21. 7:49 keltezéssel, Zhe Liu írta:

Hi Raphael Bircher,
Did you run the testing successfully? I wanna get some feedback to improve it.

I tried to run tests, but I can not start it.
The build run OK.
When I try to configure the Junit for 
testscript/src/testcase/SayHelloToOO.java,  I can add VM arguments, but 
the test class is empty and I can not add any value to it.
When I add to class test, I get error messeage:  Can not find test 
class 'test' in project 'AOO_test'.

I tried to search on test class, the Test selection dialogbox is empty,

Zoltan


2012/6/20 Raphael Bircher rbirc...@apache.org:

Hi Du

Am 20.06.12 11:49, schrieb Du Jing:

when you run build.xml via ant(select ant 2),please don't select test in
configuration check box,only select the prepare.dependencies.Hope can
help you~


Yes, it helps, thanks!

Greetings Raphael

Re: [Call for Review] Issue 119945 - Application crashed if undo adding caption to drawing object in sw


Hi,

On 14.06.2012 15:22, Lin Yuan wrote:

I have submit a patch to fix issue 119945. It's a crash issue when user do
group,ungroup,add caption operations for two drawing objects and then
do undo.

Detail issue info and comments of this issue please refer to
https://issues.apache.org/ooo/show_bug.cgi?id=119945
Patch info please refer to
https://issues.apache.org/ooo/attachment.cgi?id=78310

Please help review this fix. Thanks.



I am taking over the issue to review the patch.

Best regards, Oliver.

Re: [Call-for-Review] Bug 119740 (animation flash once doesn't work after save the ppt by aoo )

2012-06-21 Thread Andre Fischer


I will review this one.

-Andre

On 21.06.2012 10:59, tanmgeng wrote:

Hi all,
The fix for bug 119740 is ready.
Here is the link:
https://issues.apache.org/ooo/show_bug.cgi?id=119740
Anybody who could help to review it?
Thanks.

2012-06-21



tanmgeng

Re: [Call-for-Review] Bug 119699 (The animation effect Emphasis-FlashBulb play incorrectly after AOO saves a .ppt to another .ppt )

2012-06-21 Thread Andre Fischer

In the issue you say that it will be fixed by issue 119740.  You can
mark it as duplicate yourself.

-Andre

On 21.06.2012 10:55, tanmgeng wrote:
 Hi all,
 The fix for bug 119699 is ready.
 Here is the link:
 https://issues.apache.org/ooo/show_bug.cgi?id=119699
 Anybody who could help to review it?
 Thanks.
 
 2012-06-21
 
 
 
 tanmgeng

Re: Commit message summaries


- either the plainnumber  + :
- or #number#
- or #inumber#

I can live with all but we should agree on one notation. My preference
is the first and then the second. I don't think we need the lower case
'i' anymore.

Older commit messages can be interpreted by knowing the older
conventions and today we have only one bugtracker.


I disagree. Undecorated issue numbers cause gratuitous confusion and 
here is an example from a very recent commit:


 + // #119459# for connector shape, the start point and end point [...]

Now compare that with typical lines from the the AOO 3.4 (and OOo) code 
base such as main/vcl/source/window/winproc.cxx:2369

   // #119709# for some unknown reason it is possible to receive [...]
or main/sw/source/core/unocore/unodraw.cxx:2123
   // -- OD 2005-02-02 #119236# - no delete of draw format for members

The source line from the recent commit refers to a bug number in our 
current bugzilla instance whereas the examples from the older code refer 
to bug numbers in the pre-OOo tracker.


Can someone enlighten me using the concrete examples from above why 
using undecorated numbers is supposed to be better? How can one 
distinguish the issue numbers if they are not decorated?


Herbert

Re: Commit message summaries


Hi,

On 21.06.2012 14:10, Jürgen Schmidt wrote:

On 6/21/12 11:47 AM, Herbert Duerr wrote:

On 21.06.2012 10:17, Jürgen Schmidt wrote:


[snip]

That means we use something like

###
issuenumber  +1_line_summary/description

longer description_on_demand

patch_by_on_demand
...
###

where

issuenumber  is

- either the plainnumber  + :
- or #number#
- or #inumber#

I can live with all but we should agree on one notation. My preference
is the first and then the second. I don't think we need the lower case
'i' anymore.

Older commit messages can be interpreted by knowing the older
conventions and today we have only one bugtracker.

Issues from other bugtracker systems should be ideally duplicated in our
system. The other systems can be public or private bug tracking systems
and issue numbers of the latter ones don't help anybody.

I would like to hear other opinions of people who actually work with our
code.



I overall agree with the proposal.
Regarding the controversal discussed form of the issue number my favored 
notation is #number# followed by #inumber#. I am not in favor of the plain 
notation.


References in the code to issue numbers from pre-OOo (StarDivision) issue 
tracker should be removed. From my point of view in the Writer code (module sw) 
they are mainly used by my former personallity known as od (o...@openoffice.org).
Thus, if you find in a comment something like OD 200X-XX-XX #123456#, just 
remove this part of the comment.



Best regards, Oliver.

Re: [RELEASE][3.4.1]Release Bloker: proposing Bug 119803 - After upgrading to 3.4 RTF User Fields are not saving

2012-06-21 Thread Lin Yuan

May related to CWS vmiklos01 which refactor the RTF filter. Seems some
field related processing in sw\source\filter\ww8\rtfattributeoutput.cxx is
not implemented yet. I will do more investigation to know how many codes
need to be added and if it can be contained in 3.4.1 scope.

2012/6/21 Jürgen Schmidt jogischm...@googlemail.com

 On 6/21/12 3:45 AM, YangTerry wrote:
 
  Re-send it, seems failed last time.
 
  This is a bug about user fields lost after save in RTF file.
  This is a regression issue, it is work fine in OOo 3.3.
  ej19...@gmail.com
2012-06-07 10:23:13 UTC
  To duplicate:
  Create a rtf document with a version  3.4.
  Menu Options
  Insert
  -Field
  --Other
  ---User Fields
 
  At this point the variable list is shown.
 
  Insert a new variable and click the green check.
 
  The variable shows up in the list and appears to be saving.
 
  Insert the variable into the document to use it.
 
  Close the doc and reopen.
 
  When the document reopens the variable is not present and is
 de-referenced in the doc.
 
  This appears to be a critical error.  This function is used by many
 developers along with UNO to published merged documents.
 
  Resolution:  Downgrade OpenOffice to 3.4.
 

 +1 if it's a regression than it's fine for me. Who will take care of
 this issue?

 Juergen

build in gbuild modules

2012-06-21 Thread Andre Fischer


Hi,

I just wanted to let you know that I improved build.pl a little bit so 
that it is now possible to call 'build' in gbuild modules.  Up to now 
that lead to the message


This module has been migrated to GNU make.
You can only use build --all/--since here with build.pl
To do the equivalent of 'build  deliver' call:
make -sr

and so on.  This may be instructive the first ten times but eventually 
becomes just annoying.


Fixing this was very simple, just disable the warning, and forward 
debug=value definitions from the 'build' command line to the 'make' calls.


To make a long story short, it is now possible to eg build sw by calling
build

If you don't like the improvement then just don't call build in gbuild 
modules.


Regards,
Andre

Re: [PROPOSAL] Apache OpenOffice Conference 2012

2012-06-21 Thread Donald Harbison

On Wed, Jun 20, 2012 at 11:10 PM, Wolf Halton wolf.hal...@gmail.com wrote:

 On Wed, Jun 20, 2012 at 10:23 PM, Peter Junge peter.ju...@gmx.org wrote:

  As stated before, you can count me in for the CFP Jury. I've been a
 member
  of the jury for the OOo Conferences 2007 - 2010. In 2010, I have been the
  head of the jury. I would do this again, if no one else volunteers. But,
  it's unlikely that I will attend the AOOC 2012 in person. To my
 experience
  it's preferable if the head of jury attends in person because there are
  always last minute challenges (sometimes during the coffee break) to
 tackle.
 
  Peter
 
 
  On 6/21/2012 4:00 AM, Donald Harbison wrote:
 
  Forgive the top posting... I am just alerting everyone that I have
 updated
  the planning wiki [1] today with the latest proposal content, conference
  information and work items. We need volunteers, your attention and
 action.
   Please take the time to read up, and respond back on this thread with
  questions and discussion.
 
  If you decide to volunteer, please identify yourself and the aspect of
 the
  project you are most interested to help with.
 
  Thanks!
 
  On Fri, Jun 8, 2012 at 3:11 PM, Donald Harbison dpharbi...@gmail.com
  wrote:
 
   We have the opportunity to frame up and build a 'conference within a
  conference' within the ApacheCON EU 2012 venue, November 5 - 9th in
  Sinsheim, Germany. I've pulled  an outline together on the wiki [1].
 
  This is a 'call-to-action'. If you want to see this idea become a
  reality,
  now is the time to volunteer.
 
  Timing is urgent here. In the northern hemisphere, many of us will go
 off
  on vacations in July and August. We need to earn our space from ConComm
  and
  the other ApacheCon volunteers if this idea has any hope of success.
 Note
  that if you volunteer for this effort, you will also need to help out
  with
  the broader conference as well. Share and share alike!
 
  I have asked that we sharpen our proposal and submit it to ConComm by
  Friday, June 22nd... in two weeks time. Yes, that's compressed, but I
  believe we have sufficiently experienced PPMC members who know what it
  takes to make something like this happen. I've started a proposed
  committee
  list on the wiki, but that's all it is a 'start'.
 
  This is a great opportunity to re-boot our OpenOffice community in its
  country of origin. I'm personally very excited about this, and hope you
  are
  too. Please engage and make this happen.
 
  [1] *http://s.apache.org/4cp*
 
 
 
 
  Hi Don et al,
 I would like to help, but I am based in the US and do not have travel funds
 to go (as of today). Is there anything I can do to help facilitate the
 conference from Atlanta GA?


Thanks Wolf. I think advising on how to shape the tracks,
reviewing/selecting papers submitted via the CFP are good ways to help.

Much appreciated.



 Wolf


 --
 This Apt Has Super Cow Powers - http://sourcefreedom.com
 Open-Source Software in Libraries - http://FOSS4Lib.org
 Advancing Libraries Together - http://LYRASIS.org
 Apache Open Office Developer wolfhal...@apache.org

Re: Commit message summaries

2012-06-21 Thread Armin Le Grand


Hi,

On 21.06.2012 14:10, Jürgen Schmidt wrote:

On 6/21/12 11:47 AM, Herbert Duerr wrote:

[..]

good point and I agree.

That means we use something like

###
issuenumber + 1_line_summary/description

longer description_on_demand

patch_by_on_demand
...
###

where

issuenumber is

- either the plain number + :
- or #number#
- or #inumber#

I can live with all but we should agree on one notation. My preference
is the first and then the second. I don't think we need the lower case
'i' anymore.


For me in the order of preference I would use:
- #number# (we have only one tracker, no need for flags like 'i')
- #inumber#

I would not like plain number + :, it is just too hard to recognize 
(also to grep for). Maybe it's years of training, but I can simply 
immediately scan if in a task and/or description a Task-ID is included 
or not, just because of the #-usages.


Removal of older tokenized values will depend on being able to identify 
those reliable 100% which I doubt being possible. I sometimes just enter 
a found ID to bugracker, if it does not exist, it's old. If it does 
exist, a short look at it normally makes clear if it is related or not 
(because it was from another tracker). Inconvenient, but better than 
nothing *sigh*.



Older commit messages can be interpreted by knowing the older
conventions and today we have only one bugtracker.

Issues from other bugtracker systems should be ideally duplicated in our
system. The other systems can be public or private bug tracking systems
and issue numbers of the latter ones don't help anybody.


+1


I would like to hear other opinions of people who actually work with our
code.

Juergen



I'm also against using a bare issue number, because having a number that
can be reliably parsed by eventual tools (e.g. a tool that updates
bugzilla with the revision number, a tool that links the revision commit
to the corresponding bug URL, etc.) is no extra effort whereas it opens
a whole world of opportunities. I prefer that computers do such work
that can be automated because they are rather good at that.


fix:short description/summary


I like the commit conventions used in the linux kernel. Browse some
commit links of the kernel shortlog at

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog
to see some examples.


A common notation used by all would be of course helpful


+1

Herbert

Re: [Proposal] Guidelines for list conduct policy

On Tue, Jun 19, 2012 at 4:42 PM, drew d...@baseanswers.com wrote:

 On Tue, 2012-06-19 at 16:21 -0700, Kay Schenk wrote:
  On Tue, Jun 19, 2012 at 3:33 PM, drew d...@baseanswers.com wrote:
 
   On Wed, 2012-06-20 at 00:14 +0200, RGB ES wrote:
2012/6/20 drew jensen drewjensen.in...@gmail.com:

 List Conduct Policy

1.
What Happens on the list, stays on the list:
Anything you read in the private list is by default a private
 PPMC
affair and not to be spoken of, or copied to, other people who
 are
   not in
the PPMC.  If you think about it, most topic threads probably
   should
 be in
the public lists, except choosing committers and PPMC members,
 and
   a very
few other topics.
In fact, all email lists or email conversations have this
 aspect of
privacy. Even if there are 23000 subscribers on the list, it is
   assumed
that privacy will be maintained and a list member's name and
   location
 will
not be disclosed in some public venue where personal privacy
 is not
 expected,
such as published in a newspaper or some other.

 hi,

 I would disagree with that last statement completely - a public
 list is
 just that, public, and there should be absolutely no expectation of
 privacy whatsoever. To pretend otherwise is simply to lie to those
 who
 would use the list.

 //drew
   
Point one refers to the private lists, I think.
   
Maybe add a point zero with an introduction to the mailing lists,
 as
Ross asked? Not a detailed introduction, just to say most lists are
public but one is private. Then the code of conduct can be
 separated
on a general part that apply to all lists and a second part with
additional rules (for instance, the privacy one) for the private
 list.
   
Ricardo
   
  
   OK if that is really just about private lists, but the last sentence
   read to me as if it was broader.
  
   Anyway - to be honest I find the whole subject rather silly. Does
 anyone
   really need to be told that what happens on a private list is by
   definition to be held in confidence?
  
   //drew
  
  
  
  Well, Drew, I think this is why this whole discussion started. Most of us
  would think the answer to your question is no, but, well, apparently
  there was some looser interpretation that some felt needed
  clarification.

 Not at all - someone violated that trust, everyone knew it was wrong,
 there didn't need to be rules written for folks to know that.


yeah, well...IMO, this is how most rules come about. Trust gets violated,
or common sense goes out the window, or something...



 But that is just my opinion of course.


your opinion is valid...



 
  Anyway, Wolf, this is really good. I think this would be better posted as
  just a link on the project site,
 http://incubator.apache.org/openofficeorg/,
  under the Mailing Lists link, and give more clarification on item #1 that
  this most importantly applies to private mailing lists. Drew's right that
  we don't want to mislead people to think anything else is private.
 
  I think maybe it's a bit lengthy to add to a welcome message to list
  subscribers.
 
 
 





-- 

MzK

Known commonly as the jackass, this long-eared little creature
is respected throughout the southwest—roundly cursed
yet respected—and here he is usually referred to by his
Spanish name, burro. Because of his extraordinary bray,
he is sometimes ironically called the Arizona Nightingale.

 -- Arizona, the Grand Canyon State: A State Guide,
  By Federal Writers' Project

Re: [Proposal] Guidelines for list conduct policy

On Tue, Jun 19, 2012 at 5:28 PM, Wolf Halton wolf.hal...@gmail.com wrote:

 On Tue, Jun 19, 2012 at 7:51 PM, Wolf Halton wolf.hal...@gmail.com
 wrote:

 
 
  On Tue, Jun 19, 2012 at 7:42 PM, drew d...@baseanswers.com wrote:
 
  On Tue, 2012-06-19 at 16:21 -0700, Kay Schenk wrote:
   On Tue, Jun 19, 2012 at 3:33 PM, drew d...@baseanswers.com wrote:
  
On Wed, 2012-06-20 at 00:14 +0200, RGB ES wrote:
 2012/6/20 drew jensen drewjensen.in...@gmail.com:
 
  List Conduct Policy
 
 1.
 What Happens on the list, stays on the list:
 Anything you read in the private list is by default a
 private
  PPMC
 affair and not to be spoken of, or copied to, other people
  who are
not in
 the PPMC.  If you think about it, most topic threads
 probably
should
  be in
 the public lists, except choosing committers and PPMC
  members, and
a very
 few other topics.
 In fact, all email lists or email conversations have this
  aspect of
 privacy. Even if there are 23000 subscribers on the list, it
  is
assumed
 that privacy will be maintained and a list member's name and
location
  will
 not be disclosed in some public venue where personal privacy
  is not
  expected,
 such as published in a newspaper or some other.
 
  hi,
 
  I would disagree with that last statement completely - a public
  list is
  just that, public, and there should be absolutely no expectation
  of
  privacy whatsoever. To pretend otherwise is simply to lie to
  those who
  would use the list.
 
  //drew

 Point one refers to the private lists, I think.

 Maybe add a point zero with an introduction to the mailing
 lists,
  as
 Ross asked? Not a detailed introduction, just to say most lists
 are
 public but one is private. Then the code of conduct can be
  separated
 on a general part that apply to all lists and a second part with
 additional rules (for instance, the privacy one) for the private
  list.

 Ricardo

   
OK if that is really just about private lists, but the last sentence
read to me as if it was broader.
   
Anyway - to be honest I find the whole subject rather silly. Does
  anyone
really need to be told that what happens on a private list is by
definition to be held in confidence?
   
//drew
   
   
   
   Well, Drew, I think this is why this whole discussion started. Most of
  us
   would think the answer to your question is no, but, well, apparently
   there was some looser interpretation that some felt needed
   clarification.
 
  Not at all - someone violated that trust, everyone knew it was wrong,
  there didn't need to be rules written for folks to know that.
 
  But that is just my opinion of course.
 
  
   Anyway, Wolf, this is really good. I think this would be better posted
  as
   just a link on the project site,
  http://incubator.apache.org/openofficeorg/,
   under the Mailing Lists link, and give more clarification on item #1
  that
   this most importantly applies to private mailing lists. Drew's right
  that
   we don't want to mislead people to think anything else is private.
  
   I think maybe it's a bit lengthy to add to a welcome message to list
   subscribers.
  
  
  
 
 
 
  The #1 entry is the most reactionary meaning it is in reaction to an
  event or events which we as a group never want to see again, and such is
  probably a dangerous step toward totalitarianism.  I, and others  have
  defanged it somewhat.  I know it needs to be clarified to limit its scope
  to only the private lists or specifically the PPMC list and Security
 list.
  Maybe that paragraph should be #7 and something else should be at the
 top,
  as there are only a small percentage who are members of the PPMC/Security
  and a lot more who are part of dev@ or Users@ or marketing@ etc..
 
  -Wolf
 
 
  --
  This Apt Has Super Cow Powers - http://sourcefreedom.com
  Open-Source Software in Libraries - http://FOSS4Lib.org
  Advancing Libraries Together - http://LYRASIS.org
  Apache Open Office Developer wolfhal...@apache.org
 
 
 Here is the adjusted version:
 I put Dave's #7 as #0 and a reminder of the AOO mission and implications
 thereof as #1. The private-lists entry is now at the bottom.

 -Wolf
 +++

 List Conduct Policy

   1.

   Respect one another:
   Discussion is the cornerstone of a project like this and the sharing of
   viewpoints is crucial, as is understanding and accepting that many views
   will differ from your own. By all means debate rigorously and defend your
   view point stoutly, but avoid abrasive dialogue and personal attacks.
 Give
   leeway to people who do not have English as a first language. Pause
 before
   taking insult, and pause before responding. There is a difference between
   robust discussion and steamrollering. Civility is paramount. Manners cost

Re: Tutorial: How to Use the Apache CMS Web Interface

On Wed, Jun 20, 2012 at 7:07 AM, Rob Weir robw...@apache.org wrote:

 On Wed, Jun 20, 2012 at 1:58 AM, Jürgen Schmidt
 jogischm...@googlemail.com wrote:
  On 6/15/12 3:09 PM, Rob Weir wrote:
  My first attempt making a video with Camtasia.  Hopefully this will be
  useful to someone starting to use the CMS for the first time:
 
  http://www.youtube.com/watch?v=xcDZN3Lu6HA
 
 
  well done, I love short video tutorials ;-) with a good fresh coffee at
  hand.
 
  Maybe you can share some more experience how you create it, what steps
  are necessary to trim the video etc.
 

 This was done with a 30-day trial version of Camtasia Studio:
 http://www.techsmith.com/camtasia.html

 It works like a screen capture tool:  You define what area of the
 screen you want to record, what audio device to capture, etc.  After
 recording it has a simple editor to insert titles, transitions, remove
 unnecessary pauses, etc.  Finally, it takes the project, encodes it as
 WMV and automatically uploads it to YouTube.  There is a lot more
 depth to the Camtasia features -- I only scratched the surface -- but
 you can get a lot done with just the basic features.

 Other than that, the idea is the same as any tutorial, whether given
 live, printed, video, podcast, whatever.  Have a clear idea of what
 you want the user to take away, and break it down into clear steps.


I'm familiar with Camtasia but not have used it personally...it would be
nice to investigate the open source alternative Roberto mentions. It would
be a nice attribution to the camstudio.org group if we setup a YouTube area.



  I can think of many more such short video tutorials describing features
  in the office.
 
  For example many users don't know the concept of styles. So how about a
  short video explaining style and to create and use one. Or edit/change
  an existing one...
 

 Another idea would be a set of short videos examining each of the new
 features in AOO 3.4.


that would be good too!




  Many many short videos of the same style, means common intro page
  pointing to our project + content video + common finish with further
  info regarding the project or something like that.
 

 Maybe also a common place on Youtube for these.


+1



  Right now the videos
 are just in my personal account.  But it would be better,  think, if
 we had an AOO-branded account where such things could live.  This
 would make it easier for the users to find.


Yes! Maybe Drew would be willing to port his videos there also.
A sterling idea!



 Or maybe the way to do this is via common tagging?

  It's perfect promotion for our project in several ways. We provide
  useful tutorials that help our users, we show how easy it can be to join
  the project and do something useful, we do some good marketing for our
  project in general...
 
 
  Juergen
 
 




-- 

MzK

Known commonly as the jackass, this long-eared little creature
is respected throughout the southwest—roundly cursed
yet respected—and here he is usually referred to by his
Spanish name, burro. Because of his extraordinary bray,
he is sometimes ironically called the Arizona Nightingale.

 -- Arizona, the Grand Canyon State: A State Guide,
  By Federal Writers' Project

Re: [EVENT] OSCON?

2012-06-21 Thread Ross Gardler

I'll be there, but not planning to represent the AOO project. Of course if
there is anything I can do while there...

From a mobile device - forgive errors and terseness
On Jun 21, 2012 3:57 PM, Donald Harbison dpharbi...@gmail.com wrote:

 Is anyone planning on attending OSCON 2012 in Portland Oregon, July 16 -
 20?  http://www.oscon.com/oscon2012
 It'd be great to know if the project will have any representation there.

Re: Tutorial: How to Use the Apache CMS Web Interface

2012-06-21 Thread Dave Fisher

Totally agree. Very well done.

Regards,
Dave

On Jun 20, 2012, at 4:50 AM, Joe Schaefer wrote:

 This is awesome Rob- I plan to link to it from the CMS docs
 on www.apache.org.  Very well done.
 
 
 
 - Original Message -
 From: Jürgen Schmidt jogischm...@googlemail.com
 To: ooo-dev@incubator.apache.org
 Cc: 
 Sent: Wednesday, June 20, 2012 1:58 AM
 Subject: Re: Tutorial: How to Use the Apache CMS Web Interface
 
 On 6/15/12 3:09 PM, Rob Weir wrote:
 My first attempt making a video with Camtasia.  Hopefully this will be
 useful to someone starting to use the CMS for the first time:
 
 http://www.youtube.com/watch?v=xcDZN3Lu6HA
 
 
 well done, I love short video tutorials ;-) with a good fresh coffee at
 hand.
 
 Maybe you can share some more experience how you create it, what steps
 are necessary to trim the video etc.
 
 I can think of many more such short video tutorials describing features
 in the office.
 
 For example many users don't know the concept of styles. So how about a
 short video explaining style and to create and use one. Or edit/change
 an existing one...
 
 Many many short videos of the same style, means common intro page
 pointing to our project + content video + common finish with further
 info regarding the project or something like that.
 
 It's perfect promotion for our project in several ways. We provide
 useful tutorials that help our users, we show how easy it can be to join
 the project and do something useful, we do some good marketing for our
 project in general...
 
 
 Juergen

Re: Commit message summaries

2012-06-21 Thread Rob Weir

On Thu, Jun 21, 2012 at 8:10 AM, Jürgen Schmidt
jogischm...@googlemail.com wrote:
 On 6/21/12 11:47 AM, Herbert Duerr wrote:
 On 21.06.2012 10:17, Jürgen Schmidt wrote:
 We have already introduced the Patch by, Review By .. fields for adding
 further information.

 How about logs like

 
 issuenumber:issue subject line

 I agree that the issue subject line is better than nothing, but I prefer
 that the subject line is about why the change was made. See e.g. the six
 different changes for issue 118923. Why would anyone want the same
 change header for each commit when you can have a description instead
 that matches the change much better?

 good point and I agree.

 That means we use something like

 ###
 issuenumber + 1_line_summary/description

 longer description_on_demand

 patch_by_on_demand
 ...
 ###

 where

 issuenumber is

 - either the plain number + :
 - or #number#
 - or #inumber#

 I can live with all but we should agree on one notation. My preference
 is the first and then the second. I don't think we need the lower case
 'i' anymore.

 Older commit messages can be interpreted by knowing the older
 conventions and today we have only one bugtracker.


It may also be possible to change a commit message using svn propedit.
 Does anyone know if this is enabled for committer access?

See:   http://subversion.apache.org/faq.html#change-log-msg

This could also be useful for older commits that used a different
format for patch by: acknowledgements.

-Rob


 Issues from other bugtracker systems should be ideally duplicated in our
 system. The other systems can be public or private bug tracking systems
 and issue numbers of the latter ones don't help anybody.

 I would like to hear other opinions of people who actually work with our
 code.

 Juergen


 I'm also against using a bare issue number, because having a number that
 can be reliably parsed by eventual tools (e.g. a tool that updates
 bugzilla with the revision number, a tool that links the revision commit
 to the corresponding bug URL, etc.) is no extra effort whereas it opens
 a whole world of opportunities. I prefer that computers do such work
 that can be automated because they are rather good at that.

 fix:short description/summary

 I like the commit conventions used in the linux kernel. Browse some
 commit links of the kernel shortlog at

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog
 to see some examples.

 A common notation used by all would be of course helpful

 +1

 Herbert

Re: Commit message summaries

2012-06-21 Thread sebb

On 21 June 2012 19:10, Rob Weir robw...@apache.org wrote:
 On Thu, Jun 21, 2012 at 8:10 AM, Jürgen Schmidt
 jogischm...@googlemail.com wrote:
 On 6/21/12 11:47 AM, Herbert Duerr wrote:
 On 21.06.2012 10:17, Jürgen Schmidt wrote:
 We have already introduced the Patch by, Review By .. fields for adding
 further information.

 How about logs like

 
 issuenumber:issue subject line

 I agree that the issue subject line is better than nothing, but I prefer
 that the subject line is about why the change was made. See e.g. the six
 different changes for issue 118923. Why would anyone want the same
 change header for each commit when you can have a description instead
 that matches the change much better?

 good point and I agree.

 That means we use something like

 ###
 issuenumber + 1_line_summary/description

 longer description_on_demand

 patch_by_on_demand
 ...
 ###

 where

 issuenumber is

 - either the plain number + :
 - or #number#
 - or #inumber#

 I can live with all but we should agree on one notation. My preference
 is the first and then the second. I don't think we need the lower case
 'i' anymore.

 Older commit messages can be interpreted by knowing the older
 conventions and today we have only one bugtracker.


 It may also be possible to change a commit message using svn propedit.
  Does anyone know if this is enabled for committer access?

AFAIK, if the login can commit, it can also change the log message;
there's no separate karma needed.

 See:   http://subversion.apache.org/faq.html#change-log-msg

 This could also be useful for older commits that used a different
 format for patch by: acknowledgements.

 -Rob


 Issues from other bugtracker systems should be ideally duplicated in our
 system. The other systems can be public or private bug tracking systems
 and issue numbers of the latter ones don't help anybody.

 I would like to hear other opinions of people who actually work with our
 code.

 Juergen


 I'm also against using a bare issue number, because having a number that
 can be reliably parsed by eventual tools (e.g. a tool that updates
 bugzilla with the revision number, a tool that links the revision commit
 to the corresponding bug URL, etc.) is no extra effort whereas it opens
 a whole world of opportunities. I prefer that computers do such work
 that can be automated because they are rather good at that.

 fix:short description/summary

 I like the commit conventions used in the linux kernel. Browse some
 commit links of the kernel shortlog at

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog
 to see some examples.

 A common notation used by all would be of course helpful

 +1

 Herbert

Re: Commit message summaries

2012-06-21 Thread Pedro Giffuni

Hi;

--- Gio 21/6/12, Armin Le Grand armin.le.gr...@me.com ha scritto:
...
 
 For me in the order of preference I would use:
 - #number# (we have only one tracker, no need for
 flags like 'i')
 - #inumber#
 
 I would not like plain number + :, it is just too
 hard to recognize (also to grep for).

I personally find the #bznumber# notation ugly.

I prefer:
ibznumber - Short description.

but I also use
_
Short Description

Long description

Issue:   number
Author:  name
Reviewed by: name2
Discussed with: name3
_

I actually prefer the last one because the issue number
takes space from the header and we shouldn't need to
check bugzilla to make a good idea of the change.

Of course it's just me and I will adhere to the
notation decided by the project.

Pedro.

Re: [DISCUSS]What is the criteria for 3.4.1 release blocker?

2012-06-21 Thread Shenfeng Liu

Hi, Juergen,

发自我的 iPhone

在 2012-6-21，13:42，Jürgen Schmidt jogischm...@googlemail.com 写道：

 On 6/21/12 12:40 PM, Shenfeng Liu wrote:
 I wonder if any one can help to update this criteria to 3.4.1 wiki ?
 
 I am not sure what you mean, do you mean to add a link on the wiki page
 to the definition of showstopper?

Yes, add a link if definition is already somewhere, or add a section in the 
wiki page to list the criteria, since as I remember this question was asked 
several times before... List it on wiki may not reduce the frequency of the 
asking in ooo-dev mail thread, but can save us from recalling what was answered 
last time. :-P

 
 
 https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Feature+Planning
 
 by the way I moved this page under Releases - AOO 3.4.1 but the link
 still works
 
 The idea was to reduce the redundant version number in each page name,
 see
 https://cwiki.apache.org/confluence/display/OOOUSERS/Unofficial+Developer+Snapshots
 
 But as I have noticed afterwards it doesn't really work because the page
 itself is under OOOUSERS directly. I thought it would be saved
 hierarchical as in mediawiki :-(
 
 
 It was my favorite, but I'm on vacation now and difficult to update the wiki 
 from my phone...
 
 enjoy your vacation
 
 Juergen
 
 
 - Simon
 
 
 发自我的 iPhone
 
 在 2012-6-21，7:54，De Bin Lei le...@apache.org 写道：
 
 Juergen, thank for your comments, now the criteria is more clear, thanks
 again.
 
 2012/6/21 Jürgen Schmidt jogischm...@googlemail.com
 
 On 6/21/12 5:51 AM, Dennis E. Hamilton wrote:
 I think safety is of high value.
 
 That includes security issues and also data loss/corruption.  The last
 includes crashers that result in unrecoverable loss of work.  Hidden loss
 of work and document corruption that does not appear until the document is
 opened later is particularly serious.
 
 
 
 We used in general the following criteria (details where we are more
 less based on can be foud under [2])
 
 - crashes (including data loss/corruption)
 - security fixes
 - regressions
 
 I would also include
 - memory leaks
 when a fix is available and it is well tested that nothing else breaks
 
 
 - maintenance issues (like updating reference type library, version
 strings, images, ...)
 
 
 A micro release like 3.4.1 is only for fixing serious problems and not
 to introduce new features. Excepting new translations.
 
 Minor releases, eg. 3.5, can include any kind of fix, features and
 improvements. Bigger UI changes should be discussed and probably better
 included in a major release.
 
 See also [1] and especially [2]
 
 We should update these pages on demand to reflect our guideline how we
 want handle this in the future. A common understanding is of course
 important here.
 
 
 Juergen
 
 
 [1] http://wiki.services.openoffice.org/wiki/Release_criteria
 [2] http://wiki.services.openoffice.org/wiki/Stopper
 
 
 - Dennis
 
 -Original Message-
 From: dongjun zong [mailto:zongdj...@gmail.com]
 Sent: Wednesday, June 20, 2012 20:31
 To: ooo-dev@incubator.apache.org
 Subject: Re: [DISCUSS]What is the criteria for 3.4.1 release blocker?
 
 I think high severity regression issue, common usage function related
 issue
 should be considered as release blocker.
 
 2012/6/21 Ji Yan yanji...@gmail.com
 
 From my point of view, security and high usability issue should be set
 as
 blocker
 
 2012/6/21 debin lei le...@apache.org
 
 Hi, All
 I noticed that there are some issues, which are proposed as 3.4.1
 release
 blocker recently. However, I am not sure what is the criteria for the
 release blocker?
 Is it regression or impact serious ? Or high benefit to risk ratio from
 dev
 view ?
 I think maybe consider more things, but not sure.
 So if you can give your criteria and discuss here to make the things
 more
 clear will be very helpful.
 Thanks.
 
 Best regards.
 Lei De Bin
 
 
 
 
 --
 
 
 Thanks  Best Regards, Yan Ji
 
 
 
 --
 Best regards
 Lei De Bin

Re: [VCLAuto] Problems with build.xml

2012-06-21 Thread Raphael Bircher

Hi Zhe Liu

Am 21.06.12 07:49, schrieb Zhe Liu:
 Hi Raphael Bircher,
 Did you run the testing successfully? I wanna get some feedback to improve it.


I think, the tool itself works, but I run in same trubble. Take a look
at http://people.apache.org/~rbircher/download/ooo_bugs/vclauto/ maybe
you can help me.

Same feedback from the tool. I can compare, because i worked with both.

Installation.
Both, the old and the new TT are not easy to install. The old one was
not so easy cause configuration and so on. The new one is not easy
because of the depencity (Ant, Eclipse, junit) So, it's only samething
for power Users.

I find it harder to execute the new Testtool as the old one. By the old
one you have had simply to load the script and run it. By the new one
you have to take a look to the parameters. But this is only a entry
barriere.

Debuging: Sametimes usefull can be the screenshot wich are taken by the
VCLAuto. I see no avantage by searching the errors. By both you have to
understand source Code. For my point of view it's more a question of the
taste, Java or Basic. The Scipts from VCLAuto are more readable, because
they ar small and smart. But i have no illusion here, this will change
over the time ;-)

From the points above, VCLAuto and VCLTestTool are equal solutions.
Well, VCLAuto is maybe newer. But I have two big critisme to VCLAuto

- VCLAuto can't test Localized Builds at the moment.
- We have much less tests for VCLAuto then for the VCLTestTool (I beleve
that the old TestTool covers 20 Times more then the VCLAuto Tests now)
This is also the reason why VCLTestTool use much more time to run.
VCLAuto is not realy faster, it has simply less Testcase, and from a QA
point of view, this is bad news.

From my point of view, the VCL auto is atm not a equal replacement for
the VCLTestTool. The VCLAuto is indeed the fresher tool, but also less
mature. I support the move to VCLAuto, but i also have to remind every
one here that there is still a load of Work.

Greetings Raphael

Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633

On 06/19/2012 01:18 PM, Marcus (OOo) wrote:

Am 06/19/2012 01:15 PM, schrieb J�rgen Schmidt:

Hi,

I would like to propose that we prepare the first set of dev snapshots
for AOO 3.4.1 based on the revision r1351633.

We will start from now on to build and provide a dev snapshot every week
for testing purposes.

We can include Finnish and British English already because I have update
both languages ones for testing.

Languages for now: en-US ar cs de en-GB es fi fr gl hu it ja nl ru pt-BR
zh-CN zh-TW

Further languages can be included and the dead line is still end of June
as proposed in my initial plan.

I am trying to work on all requests for further languages, please send
me a reminder if I have forget a language or if I have forgot to send
you the po files.

The builds will be made available under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots

Great to see progress with new Dev Builds.

I would suggest to reuse the old page (rename it first to get rid of the
version number). Then you don't need always to build up a new page and
the download webpage doesn't need to be updated everytime with a new
link which difference is just the version number.

So, a webpage URL name like this would be better and chances to live
longer are much higher. ;-)

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Unofficial+Developer+Snapshots

Marcus

Marcus...probably a good idea. I didn't see your post in this thread and
saw we were already a couple of days out on this, so I just changed the
old developer link on download/index.html

MzK

There's no crying in baseball!
-- Jimmy Dugan (Tom Hanks), A League of Their Own

Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633


Hi,


On 06/19/2012 01:18 PM, Marcus (OOo) wrote:

Am 06/19/2012 01:15 PM, schrieb Jürgen Schmidt:

[...]
The builds will be made available under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots


Great to see progress with new Dev Builds.

I would suggest to reuse the old page (rename it first to get rid of the
version number). Then you don't need always to build up a new page and
the download webpage doesn't need to be updated everytime with a new
link which difference is just the version number.

So, a webpage URL name like this would be better and chances to live
longer are much higher. ;-)

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Unofficial+Developer+Snapshots


I agree, using a page with a stable page name such as the
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
would be better. That's why I had created it many months ago. I suggest 
to add the details of our next development snapshot builds to that page 
instead of the short-lived micro-release-specific pages.


On 06/22/2012 12:22 AM, Kay Schenk wrote:

Marcus...probably a good idea. I didn't see your post in this thread and
saw we were already a couple of days out on this, so I just changed the
old developer link on download/index.html


Thanks. That was a good idea.
I think you agree that not having to update the link to new snapshot 
builds every time would be better?


Herbert

Re: [VCLAuto] Problems with build.xml

On 6/21/12 11:50 PM, Raphael Bircher wrote:
 Hi Zhe Liu
 
 Am 21.06.12 07:49, schrieb Zhe Liu:
 Hi Raphael Bircher,
 Did you run the testing successfully? I wanna get some feedback to improve 
 it.


 I think, the tool itself works, but I run in same trubble. Take a look
 at http://people.apache.org/~rbircher/download/ooo_bugs/vclauto/ maybe
 you can help me.
 
 Same feedback from the tool. I can compare, because i worked with both.
 
 Installation.
 Both, the old and the new TT are not easy to install. The old one was
 not so easy cause configuration and so on. The new one is not easy
 because of the depencity (Ant, Eclipse, junit) So, it's only samething
 for power Users.
 
 I find it harder to execute the new Testtool as the old one. By the old
 one you have had simply to load the script and run it. By the new one
 you have to take a look to the parameters. But this is only a entry
 barriere.
 
 Debuging: Sametimes usefull can be the screenshot wich are taken by the
 VCLAuto. I see no avantage by searching the errors. By both you have to
 understand source Code. For my point of view it's more a question of the
 taste, Java or Basic. The Scipts from VCLAuto are more readable, because
 they ar small and smart. But i have no illusion here, this will change
 over the time ;-)
 
 From the points above, VCLAuto and VCLTestTool are equal solutions.
 Well, VCLAuto is maybe newer. But I have two big critisme to VCLAuto
 
 - VCLAuto can't test Localized Builds at the moment.
 - We have much less tests for VCLAuto then for the VCLTestTool (I beleve
 that the old TestTool covers 20 Times more then the VCLAuto Tests now)
 This is also the reason why VCLTestTool use much more time to run.
 VCLAuto is not realy faster, it has simply less Testcase, and from a QA
 point of view, this is bad news.
 
 From my point of view, the VCL auto is atm not a equal replacement for
 the VCLTestTool. The VCLAuto is indeed the fresher tool, but also less
 mature. I support the move to VCLAuto, but i also have to remind every
 one here that there is still a load of Work.

nobody said that the new tool is a 100% replacement of the old tool. The
old one is not maintained anymore and nobody writes new tests :-( The
new one is a clean fresh implementation where people know the code and
where people have interest to maintain it. And of course where people
have started to write either new tests or convert old existing tests.

Our challenge is to build some new knowledge in this area and document
everything to make it easy for people to get started and to help.

Juergen

Re: build in gbuild modules


Hi,

On 21.06.2012 16:52, Andre Fischer wrote:

Hi,

I just wanted to let you know that I improved build.pl a little bit so that it
is now possible to call 'build' in gbuild modules. Up to now that lead to the
message

This module has been migrated to GNU make.
You can only use build --all/--since here with build.pl
To do the equivalent of 'build  deliver' call:
make -sr

and so on. This may be instructive the first ten times but eventually becomes
just annoying.

Fixing this was very simple, just disable the warning, and forward debug=value
definitions from the 'build' command line to the 'make' calls.

To make a long story short, it is now possible to eg build sw by calling
build

If you don't like the improvement then just don't call build in gbuild modules.



Thank you very much.
I will use build in the future.

Best regards, Oliver.

Re: [RELEASE][3.4.1][DEV-BUILD]: propose first dev snapshot build for AOO 3.4.1 based on revision 1351633

On 6/22/12 7:05 AM, Herbert Duerr wrote:
Hi,

On 06/19/2012 01:18 PM, Marcus (OOo) wrote:
Am 06/19/2012 01:15 PM, schrieb Jürgen Schmidt:
[...]
The builds will be made available under
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Unofficial+Developer+Snapshots

Great to see progress with new Dev Builds.

So, a webpage URL name like this would be better and chances to live
longer are much higher. ;-)

https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+Unofficial+Developer+Snapshots

I agree, using a page with a stable page name such as the
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds

would be better. That's why I had created it many months ago. I suggest
to add the details of our next development snapshot builds to that page
instead of the short-lived micro-release-specific pages.

you didn't promote this page good enough ;-)

But as I mentioned yesterday I am not very happy with the current
structure and it is not well structured.
I didn't remember that the wiki page is linked from the download page
but that is indeed a good reason to have a more stable page.

I will move the content and will create a further section for the
upcoming 3.5 dev builds as well.

Juergen

On 06/22/2012 12:22 AM, Kay Schenk wrote:
Marcus...probably a good idea. I didn't see your post in this thread and
saw we were already a couple of days out on this, so I just changed the
old developer link on download/index.html

Thanks. That was a good idea.
I think you agree that not having to update the link to new snapshot
builds every time would be better?

Herbert

Re: build in gbuild modules