date:20130813

h...@apache.org h...@apache.org has asked  for 4.0.1_release_blocker:
Bug 122991: Provide some details about fatal exceptions in the desktop app
https://issues.apache.org/ooo/show_bug.cgi?id=122991

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

4.0.1_release_blocker requested: [Bug 122885] AOO 4.x crash with extension Readability Report 2.0.x or older

h...@apache.org h...@apache.org has asked  for 4.0.1_release_blocker:
Bug 122885: AOO 4.x crash with extension Readability Report 2.0.x or older
https://issues.apache.org/ooo/show_bug.cgi?id=122885

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

Re: Need help in translating MWiki page

2013-08-13 Thread Andrea Pescetti


On 12/08/2013 Regina Henschel wrote:

I have started a draft outline on
http://wiki.openoffice.org/wiki/Talk:Pootle_User_Guide
If you agree, I will continue in that direction.


It is a really good resource. Maybe, if it gets too long, it will be 
better to divide it inyto several pages, but it is definitely helpful. I 
added some remarks directly in the page, if you need further information 
just ask.


Regards,
  Andrea.

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

Re: [Pootle] about translating AOOE site

2013-08-13 Thread janI

On 12 August 2013 23:47, Ricardo Berlasso rgb.m...@gmail.com wrote:

 2013/8/12 janI j...@apache.org

  On 12 August 2013 11:11, janI j...@apache.org wrote:
 
  
  
  
   On 12 August 2013 11:01, Raphael Bircher r.birc...@gmx.ch wrote:
  
   Am 12.08.13 10:56, schrieb janI:
  
On 12 August 2013 10:48, Roberto Galoppini 
  roberto.galopp...@gmail.com
   **wrote:
  
Could we create a pootle project on translate.apache.org to upload
   AOOE PO
   files and get them translated?
  
I have the karma to do that, but sorry for my lack of knowledge,
 what
   is
   AOOE compared to AOO ?
  
   Apache OpenOffice Extension Website?!
  
  
   that was too simple, why did I not see that.
  
 
  Project is created, so as soon as I get the files I will put them on the
  vm. After the initial load anybody can download them, and users can
 upload
  changes.
 


 Great!

 Just a small comment: there is a typo on the project name: there is a
 missing i between the f and the c: it says Apache OpenOffce Extensions.


corrected (not by me someone was faster).

I am still waiting for the initial batch of po files, you cannot load the
primary set yourself.

In general we need .pot (po template files for en-US), these act as
template files for all languages.

Furthermore an administrator (e.g. me) needs to activate new languages,
currently no languages are active.

rgds
jan I.


 Regards
 Ricardo




 
  rgds
  jan I.
 
  
   thx.
   rgds
   jan I.
  
  
  
   If you make the po files available to me, I can do it relative fast.
  
   rgds
   jan I.
  
  
Roberto
  
  
  
  
  --**--**-
   To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org
  dev-unsubscr...@openoffice.apache.org
   For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Additional languages for buildbots

2013-08-13 Thread Herbert Duerr


On 13.08.2013 08:42, Andrea Pescetti wrote:

I see that yesterday's buildbot run completed successfully
http://ci.apache.org/projects/openoffice/#winsnap
(even though, since we are still building the SNAPSHOT tag, running that
buildbot is only testing that the buildbot works). This is the only one
where we support localization at the moment.

Before we forget, can we add to it at least
zh-TW (unsure aoput the right syntax) km pl kid ?
The first 3 languages are 100% complete in Pootle, kid is the KeyID
and it's useful to translators.


I now added km and zh-TW, pl was already there. Enabling the keyid 
build doesn't make sense until [1] is fixed. The current kid 
localization is quite out of date.


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


This is only a step in making the new languages available for testing
(the other two being: regenerating the SDF files and moving the SNAPSHOT
tag or equivalent on the buildbot side), but it is independent of the
other actions needed.

And what is preventing us from having at least one Linux buildbot
equivalent to win7snap? I thought disk space was the issue, but from
Andrew's remarks I understood this is no longer problematic under
Windows or Linux.


Last week we ran out of space on the Windows buildbot. When Andrew 
cleaned things out they started working again. With the additional 
languages we are stressing it a bit more now though.


The snapshot tag is currently only moved sporadically so spending time 
in setting up new snapshot buildbots for e.g. Linux is an arguable 
investment. For most cases the already existing nightly builds are better.


Herbert

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

4.0.1_release_blocker requested: [Bug 122836] Corruption of rotated images on MacOSX

h...@apache.org h...@apache.org has asked  for 4.0.1_release_blocker:
Bug 122836: Corruption of rotated images on MacOSX
https://issues.apache.org/ooo/show_bug.cgi?id=122836

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

Re: Unnecesary filestructure on images

On Mon, Aug 12, 2013 at 8:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 1:35 AM, Alexandro Colorado j...@oooes.org
wrote:
I think the image structure on the website is a bit messy, there has
been
some cleanup done by kschenk but I think there is still a lot of
clean up
work to be done.

For example, the new logo, was simply draged and drop to the AOOLogos
folder with a huge name. I understand the name was needed to identify
it
between the rest of the competitive logos. But now that is selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

Right. That work is incomplete. I checked it in originally, after
the logo vote, so we could start working on the product integration
immediately. But note that the above logo is not the one we actually
used in AOO 4.0 !!

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0, which
I helped check in.

My intent was to take that SVG and rename it to master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just incrementally
replace with the future logos as we update the SVG.

Here's the complication: The old logos are still relevant some some
purposes. For example, the PMC receives ongoing requests to approve
use of the old OpenOffice.org logo. Why would that happen? Often it
is a request by publishers who are making an e-book version of an
older print book. If their original request did not include the
e-book rights then they come back to us (and owners of every other
image they use) to request additional permissions.

I think that 'complication' is the lesser of two evils., compared to
having to manage a ever growing ammount of images. And beside that, do you
realize the difference in objectives between ooo-site/images/
ooo-site/marketing/art/images/ and ooo-site/branding/images.

I dont see any reason why those issues should impact the web works of
ooo-site/images/. That folder is for website-design related work. It has,
or shouldnt hold any porpouse to archieve past work, nor to hold
description of any kind. I think website should be as lean and easy to
follow since we expect these conventions be followed by a rotating
community. So again K.I.S.S.

If those complications arises, send them to marketing or branding
workspaces.

So it may be possible, going forward, to store logos as SVN revisions
under the same name. But we cannot retroactively do this with
pre-Apache logos. And even if we could, this is harder for users of
the logo to access. It is much easier to have something like
logo-330.svg available via HTTP.

svg are just like HTML files, they are markup languages, we dont hold the
index.html inmaculated and hold an apache-index.html and oracle-index.html,
so I dont see why SVG should be any different. The only porpouse of having
a source file, is for users to be able to modify it on the first place.
Either by integrating to a bigger SVG design, or resizing it for print
work.

Of course you can have a hybrid approach:

1) When a new logo is introduced, svn copy the old one into a
/old-logos directory with a new descriptive name. This preserves the
version history.

This is not functional and just start acumulating part of the same garbage
that svn is supposed to clean up. Again, if this was code, this would be
totally unacceptable approach. If new logos are introduced then they should
replace the current logo, and the old will live in anals of the svn logs.

2) New logo then is checked in as a new revision of logo-master.svg.

People are free to disagree with me, but I think this is a messy way to
work, and for a webdev folder is completely useless, specially when there
is a whole different project specialized on archiving, developing, and
multiplying artwork inside marketing, and a whole different project devoted
to specifying the guideliness of the brand (aka logo).

Regards,

-Rob

or something clean like that. However, I have not had any luck
getting this logo to load into Inkscape or Adobe Illustrator. I get
errors. And I have not had any luck getting Kevin to send a version
that will load.

So we're stuck right now with a logo that does load into Inkscape, but
is slightly different than the one we used in AOO 4.0.

Re: Unnecesary filestructure on images

On Mon, Aug 12, 2013 at 11:37 AM, Kay Schenk kay.sch...@gmail.com wrote:

On Mon, Aug 12, 2013 at 6:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org
wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org wrote:

For example, the new logo, was simply draged and drop to the
AOOLogos
folder with a huge name. I understand the name was needed to
identify
it
between the rest of the competitive logos. But now that is selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0, which
I helped check in.

My intent was to take that SVG and rename it to master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just
incrementally
replace with the future logos as we update the SVG.

Of course you can have a hybrid approach:

1) When a new logo is introduced, svn copy the old one into a
/old-logos directory with a new descriptive name. This preserves the
version history.

2) New logo then is checked in as a new revision of logo-master.svg.

I like this idea or something akin to it. We should definitely preserve
svgs for old logos in my opinion. The new branding repository can be
used for this, and given some additional structure. I'm also finding some
svg masters for items that are not really logos, like Get It Here, that
probably need to be moved to branding even though they are not really
logos.

That is because branding original intention was to document/create the
guidelines, it was 100% documentation project. ART (inside marketing) is
the one that hold the logos, banners, artwork, design elements,
microbanners, and 3d work, etc.

http://www.openoffice.org/marketing/art/

As well as other type of design like Business card templates, OOoCon
Impress templates, and such. Branding basically was just a branch on the
wiki. Eventually this was moved to the wiki.

We soon realize that managing the repository on the wiki would be a faster
and easier way since the wiki is much easier to make commits and updates to
it. Example, the splashscreen contest:

http://wiki.openoffice.org/wiki/Art/Gallery

And, because there are quite a few sites using old logo versions, I don't
really think we should track them all down and require them to upgrade.

Some groups clone the 'master' logo and this makes it a bit harder to
track, there are still some abandoned NL projects with the design from OOo
3.0 (2008/9)

AFAIK the new logo is exactly the same approach of the old logo (Apache on
top of OpenOffice and an Orb to the left). Can you explain further?

it's conceivable, depending on use, the even within the Apache OpenOffice
site, etc., different renderings might be used. But maybe this is in

[RELEASE]: preparation for AOO 4.0.1

Hi,

first if all I volunteer to act as the release manager for AOO 4.0.1 if
that is wanted but I am also open to let somebody else to the job ;-)

In preparation for an AOO 4.0.1 release I have first created a AOO400
tag based on revision 1503704. I have also created a new branch AOO401
based on branch AOO400 based on the head revision of the branch.

I noticed that Yuri checked in some code on the branch already. Can we
please follow some guideline how we handle such release branches?

I would like to propose the following:

Changes on a release branch should be discussed before and should be in
relation to a proposed and approved fix (if you want showstopper) that
will go in the next release.


For now that means the branch AOO400 is dead and changes towards AOO
4.0.1 have to be made on the new branch AOO401 and should be discussed
first. Or propose the related issue as showstopper first.

I believe we agreed more or less to keep the changes for AOO 4.0.1
minimal to reduce the test effort. We should concentrate on the most
serious issues only and on new languages or improved translations. Keep
in mind that AOO 4.1 is coming as well. Stability is a key feature and
every single bug fix can introduce a regression as well. Often not
obvious directly.


Any opinions or comment son this plan.

Juergen

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

4.0.1_release_blocker requested: [Bug 122149] repaint error when scrolling (under particular circumstances)

Armin Le Grand armin.le.gr...@me.com has asked  for 4.0.1_release_blocker:
Bug 122149: repaint error when scrolling (under particular circumstances)
https://issues.apache.org/ooo/show_bug.cgi?id=122149


--- Additional Comments from Armin Le Grand armin.le.gr...@me.com
ALG: asking for release blocker

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

4.0.1_release_blocker requested: [Bug 122913] Inteegrate Traditional Chinese into Chunks

j...@apache.org has asked  for 4.0.1_release_blocker:
Bug 122913: Inteegrate Traditional Chinese into Chunks
https://issues.apache.org/ooo/show_bug.cgi?id=122913

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

4.0.1_release_blocker granted: [Bug 122149] repaint error when scrolling (under particular circumstances)

j...@apache.org has granted Armin Le Grand armin.le.gr...@me.com's request for
4.0.1_release_blocker:
Bug 122149: repaint error when scrolling (under particular circumstances)
https://issues.apache.org/ooo/show_bug.cgi?id=122149


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122836] Corruption of rotated images on MacOSX

j...@apache.org has granted h...@apache.org h...@apache.org's request for
4.0.1_release_blocker:
Bug 122836: Corruption of rotated images on MacOSX
https://issues.apache.org/ooo/show_bug.cgi?id=122836


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122885] AOO 4.x crash with extension Readability Report 2.0.x or older

j...@apache.org has granted h...@apache.org h...@apache.org's request for
4.0.1_release_blocker:
Bug 122885: AOO 4.x crash with extension Readability Report 2.0.x or older
https://issues.apache.org/ooo/show_bug.cgi?id=122885


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122948] Copy/pasting some Complex Text Layout strings crashes OpenOffice

j...@apache.org has granted Andrea Pescetti pesce...@apache.org's request for
4.0.1_release_blocker:
Bug 122948: Copy/pasting some Complex Text Layout strings crashes OpenOffice
https://issues.apache.org/ooo/show_bug.cgi?id=122948


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122997] Calculation error in the IMABS() function

j...@apache.org has granted Regina Henschel rb.hensc...@t-online.de's request
for 4.0.1_release_blocker:
Bug 122997: Calculation error in the IMABS() function
https://issues.apache.org/ooo/show_bug.cgi?id=122997


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122991] Provide some details about fatal exceptions in the desktop app

j...@apache.org has granted h...@apache.org h...@apache.org's request for
4.0.1_release_blocker:
Bug 122991: Provide some details about fatal exceptions in the desktop app
https://issues.apache.org/ooo/show_bug.cgi?id=122991


--- Additional Comments from j...@apache.org
approve showstopper request

It will help us to analyze problems with incompatible API changes

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

4.0.1_release_blocker granted: [Bug 122913] Integrate Traditional Chinese in AOO 4.0.1

j...@apache.org has granted j...@apache.org's request for 4.0.1_release_blocker:
Bug 122913: Integrate Traditional Chinese in AOO 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=122913


--- Additional Comments from j...@apache.org
approve showstopper request

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

4.0.1_release_blocker granted: [Bug 122902] footnote deletion causes crash

j...@apache.org has granted Oliver-Rainer Wittmann o...@apache.org's request
for 4.0.1_release_blocker:
Bug 122902: footnote deletion causes crash
https://issues.apache.org/ooo/show_bug.cgi?id=122902


--- Additional Comments from j...@apache.org
approve showstopper request

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

Re: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread Rob Weir

On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 Hi,

 first if all I volunteer to act as the release manager for AOO 4.0.1 if
 that is wanted but I am also open to let somebody else to the job ;-)


It is probably best if you continue, since 4.0.1 is very closely
related to 4.0.0, and you already have the build environment set up,
etc.

 In preparation for an AOO 4.0.1 release I have first created a AOO400
 tag based on revision 1503704. I have also created a new branch AOO401
 based on branch AOO400 based on the head revision of the branch.

 I noticed that Yuri checked in some code on the branch already. Can we
 please follow some guideline how we handle such release branches?

 I would like to propose the following:

 Changes on a release branch should be discussed before and should be in
 relation to a proposed and approved fix (if you want showstopper) that
 will go in the next release.


 For now that means the branch AOO400 is dead and changes towards AOO
 4.0.1 have to be made on the new branch AOO401 and should be discussed
 first. Or propose the related issue as showstopper first.

 I believe we agreed more or less to keep the changes for AOO 4.0.1
 minimal to reduce the test effort. We should concentrate on the most
 serious issues only and on new languages or improved translations. Keep
 in mind that AOO 4.1 is coming as well. Stability is a key feature and
 every single bug fix can introduce a regression as well. Often not
 obvious directly.


I assume we also want to avoid introducing new UI strings?   Otherwise
we'd require translation updates on all languages.


 Any opinions or comment son this plan.


Should we create new Release Notes?  Or augment the existing 4.0.0
ones?   It might be simpler if 4.0.x releases share the same release
notes, but we start with fresh ones for 4.1?

-Rob

 Juergen

 -
 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: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread janI

On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote:

 On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com
 wrote:
  Hi,
 
  first if all I volunteer to act as the release manager for AOO 4.0.1 if
  that is wanted but I am also open to let somebody else to the job ;-)
 

 It is probably best if you continue, since 4.0.1 is very closely
 related to 4.0.0, and you already have the build environment set up,
 etc.

+1


  In preparation for an AOO 4.0.1 release I have first created a AOO400
  tag based on revision 1503704. I have also created a new branch AOO401
  based on branch AOO400 based on the head revision of the branch.
 
  I noticed that Yuri checked in some code on the branch already. Can we
  please follow some guideline how we handle such release branches?
 
  I would like to propose the following:
 
  Changes on a release branch should be discussed before and should be in
  relation to a proposed and approved fix (if you want showstopper) that
  will go in the next release.
 
 
  For now that means the branch AOO400 is dead and changes towards AOO
  4.0.1 have to be made on the new branch AOO401 and should be discussed
  first. Or propose the related issue as showstopper first.
 
  I believe we agreed more or less to keep the changes for AOO 4.0.1
  minimal to reduce the test effort. We should concentrate on the most
  serious issues only and on new languages or improved translations. Keep
  in mind that AOO 4.1 is coming as well. Stability is a key feature and
  every single bug fix can introduce a regression as well. Often not
  obvious directly.
 

 I assume we also want to avoid introducing new UI strings?   Otherwise
 we'd require translation updates on all languages.


I would formulate it stronger: we cannot allow new strings, unless it is
absolutely unavoidable.



 
  Any opinions or comment son this plan.
 

 Should we create new Release Notes?  Or augment the existing 4.0.0
 ones?   It might be simpler if 4.0.x releases share the same release
 notes, but we start with fresh ones for 4.1?


Lets share release notes, amend so that is clear what is only available in
4.0.1, and start from a fresh with 4.1

I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc.

rgds
jan I.



 -Rob

  Juergen
 
  -
  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

4.0.1_release_blocker requested: [Bug 122829] python ctypes library fails to import

h...@apache.org h...@apache.org has asked  for 4.0.1_release_blocker:
Bug 122829: python ctypes library fails to import
https://issues.apache.org/ooo/show_bug.cgi?id=122829

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

Re: [RELEASE]: preparation for AOO 4.0.1

On 8/13/13 3:26 PM, janI wrote:
 On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote:
 
 On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com
 wrote:
 Hi,

 first if all I volunteer to act as the release manager for AOO 4.0.1 if
 that is wanted but I am also open to let somebody else to the job ;-)


 It is probably best if you continue, since 4.0.1 is very closely
 related to 4.0.0, and you already have the build environment set up,
 etc.

 +1
 

 In preparation for an AOO 4.0.1 release I have first created a AOO400
 tag based on revision 1503704. I have also created a new branch AOO401
 based on branch AOO400 based on the head revision of the branch.

 I noticed that Yuri checked in some code on the branch already. Can we
 please follow some guideline how we handle such release branches?

 I would like to propose the following:

 Changes on a release branch should be discussed before and should be in
 relation to a proposed and approved fix (if you want showstopper) that
 will go in the next release.


 For now that means the branch AOO400 is dead and changes towards AOO
 4.0.1 have to be made on the new branch AOO401 and should be discussed
 first. Or propose the related issue as showstopper first.

 I believe we agreed more or less to keep the changes for AOO 4.0.1
 minimal to reduce the test effort. We should concentrate on the most
 serious issues only and on new languages or improved translations. Keep
 in mind that AOO 4.1 is coming as well. Stability is a key feature and
 every single bug fix can introduce a regression as well. Often not
 obvious directly.


 I assume we also want to avoid introducing new UI strings?   Otherwise
 we'd require translation updates on all languages.

 
 I would formulate it stronger: we cannot allow new strings, unless it is
 absolutely unavoidable.

indeed UI changes are not allowed for a micro update, only bugfixes. New
features should be implemented on trunk for AOO 4.1

I is so natural for me that I forgot to mention this explicitly

Juergen

 
 


 Any opinions or comment son this plan.


 Should we create new Release Notes?  Or augment the existing 4.0.0
 ones?   It might be simpler if 4.0.x releases share the same release
 notes, but we start with fresh ones for 4.1?

 
 Lets share release notes, amend so that is clear what is only available in
 4.0.1, and start from a fresh with 4.1
 
 I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc.

no, the name contains the new version

Juergen


 
 rgds
 jan I.
 
 

 -Rob

 Juergen

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


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


 


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

4.0.1_release_blocker requested: [Bug 122827] calc slow saving in xls

h...@apache.org h...@apache.org has asked  for 4.0.1_release_blocker:
Bug 122827: calc slow saving in xls
https://issues.apache.org/ooo/show_bug.cgi?id=122827

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

4.0.1_release_blocker requested: [Bug 122822] Correct viewing of XY-, Column- and Line-Charts limited to 10000 records + 1 Heading row

h...@apache.org h...@apache.org has asked  for 4.0.1_release_blocker:
Bug 122822: Correct viewing of XY-, Column- and Line-Charts limited to 1
records + 1 Heading row
https://issues.apache.org/ooo/show_bug.cgi?id=122822

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

4.0.1_release_blocker requested: [Bug 122600] [SVG] problems in SvgSvgNode

Armin Le Grand armin.le.gr...@me.com has asked  for 4.0.1_release_blocker:
Bug 122600: [SVG] problems in SvgSvgNode
https://issues.apache.org/ooo/show_bug.cgi?id=122600


--- Additional Comments from Armin Le Grand armin.le.gr...@me.com
ALG: Checked, only #122575# is not yet solved and needs to betaken out in my
opinion. All other stuff works well, compared with firefox as reference.

Well done, Regina!
Esp. using seekReferenceWidth/seekReferenceHeight is pretty much exactly what I
would have done, too ;-}

Also checked with all my collected svg bugdocs over time, all work well, no
regression visible.
Since this fixes a crash and a regression in AOO400 i request the showstopper
flag.

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

4.0.1_release_blocker granted: [Bug 122600] [SVG] problems in SvgSvgNode

j...@apache.org has granted Armin Le Grand armin.le.gr...@me.com's request for
4.0.1_release_blocker:
Bug 122600: [SVG] problems in SvgSvgNode
https://issues.apache.org/ooo/show_bug.cgi?id=122600


--- Additional Comments from j...@apache.org
approve showstopper request 

change type to defect because it solves primary a crash

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

4.0.1_release_blocker granted: [Bug 122909] Translation update for Portuguese (pt) post-4.0

j...@apache.org has granted Pedro Albuquerque pmralbuquer...@apache.org's
request for 4.0.1_release_blocker:
Bug 122909: Translation update for Portuguese (pt) post-4.0
https://issues.apache.org/ooo/show_bug.cgi?id=122909


--- Additional Comments from j...@apache.org
approve showstopper request for translation update

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

Re: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread Yuri Dario

Hi,


 I noticed that Yuri checked in some code on the branch already. Can we
 please follow some guideline how we handle such release branches?


 Changes on a release branch should be discussed before and should be in
 relation to a proposed and approved fix (if you want showstopper) that
 will go in the next release.

sorry, but maybe I'm not understanding something; why do AOO400 (which
is a branch) fixes going into next release (AOO401) require another 
branch?

I committed to AOO400 because I supposed that newer (minor) releases 
were going into this branch, not into a different one.

And I don't undestand at all why branching again for 401, while we can
just use tagging to monitor minor bugfixes releases from AOO400 
branch.

I understand that a 4.1 release will incorporate new code while we can
still produce 4.0.2 on the older branch, so branching for 4.1 makes 
more sense.

with this branching tecnique, a bugfix must be sideported to every 
active branch, e.g. trunk, AOO401, AOO410 (maybe more in the future).

If I missed some guideline doc on the wiki please excuse me.

thanks,



-- 
Bye,

Yuri Dario

/*
 * OS/2 open source software
 * http://web.os2power.com/yuri
 * http://www.netlabs.org
*/



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

Re: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread Fernando Cassia

On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 In preparation for an AOO 4.0.1 release I have first created a AOO400
 tag based on revision 1503704. I have also created a new branch AOO401
 based on branch AOO400 based on the head revision of the branch.

 I noticed that Yuri checked in some code on the branch already. Can we
 please follow some guideline how we handle such release branches?

Is there a chance to get a fix so that AOO 4.0.1 starts properly
maximized ALL THE TIME?

On Windows at least (Win7 64bit) it didn't. Of course after maximizing
it, it started maximized after the fact (probably reading the last
window size from some saved preference, but the fact that it doesn't
automagically maximize its window annoys me. Is there a bug report for
this? Anyone else seen this? Any rationale for the app not starting
maximized?.

On a related note, the first thing I do (since the StarOffice 3.1
days) when I open a new document is set zoom level to Optimal (or
optimize width, I'm not sure right now how it's called).

Why isn't this the default is beyond me. Otherwise, with the standard
zoom level lots of horizontal screen real state is wasted. Thoughts?
Comments? Expletives? ;)

FC

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

Re: [RELEASE]: preparation for AOO 4.0.1

On Tue, Aug 13, 2013 at 6:26 AM, janI j...@apache.org wrote:

 On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote:

  On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com
  wrote:
   Hi,
  
   first if all I volunteer to act as the release manager for AOO 4.0.1 if
   that is wanted but I am also open to let somebody else to the job ;-)
  
 
  It is probably best if you continue, since 4.0.1 is very closely
  related to 4.0.0, and you already have the build environment set up,
  etc.
 
 +1

 
   In preparation for an AOO 4.0.1 release I have first created a AOO400
   tag based on revision 1503704. I have also created a new branch AOO401
   based on branch AOO400 based on the head revision of the branch.
  
   I noticed that Yuri checked in some code on the branch already. Can we
   please follow some guideline how we handle such release branches?
  
   I would like to propose the following:
  
   Changes on a release branch should be discussed before and should be in
   relation to a proposed and approved fix (if you want showstopper) that
   will go in the next release.
  
  
   For now that means the branch AOO400 is dead and changes towards AOO
   4.0.1 have to be made on the new branch AOO401 and should be discussed
   first. Or propose the related issue as showstopper first.
  
   I believe we agreed more or less to keep the changes for AOO 4.0.1
   minimal to reduce the test effort. We should concentrate on the most
   serious issues only and on new languages or improved translations. Keep
   in mind that AOO 4.1 is coming as well. Stability is a key feature and
   every single bug fix can introduce a regression as well. Often not
   obvious directly.
  
 
  I assume we also want to avoid introducing new UI strings?   Otherwise
  we'd require translation updates on all languages.
 

 I would formulate it stronger: we cannot allow new strings, unless it is
 absolutely unavoidable.


 
  
   Any opinions or comment son this plan.
  
 
  Should we create new Release Notes?  Or augment the existing 4.0.0
  ones?   It might be simpler if 4.0.x releases share the same release
  notes, but we start with fresh ones for 4.1?
 

 Lets share release notes, amend so that is clear what is only available in
 4.0.1, and start from a fresh with 4.1


For 3.4.1, which was basically an update release with addtional languages,
the release notes were sort of like an addendum to 3.4.0 --


https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes

I think Release Notes for 4.0.1 should be similar but, yes, we need a new
page for them.


 I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc.

 rgds
 jan I.


 
  -Rob
 
   Juergen
  
   -
   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
 
 




-- 
-
MzK

Success is falling nine times and getting up ten.
 -- Jon Bon Jovi

Re: [RELEASE]: preparation for AOO 4.0.1

On 8/13/13 5:55 PM, Yuri Dario wrote:
 Hi,
 
 
 I noticed that Yuri checked in some code on the branch already. Can we
 please follow some guideline how we handle such release branches?
 
 
 Changes on a release branch should be discussed before and should be in
 relation to a proposed and approved fix (if you want showstopper) that
 will go in the next release.
 
 sorry, but maybe I'm not understanding something; why do AOO400 (which
 is a branch) fixes going into next release (AOO401) require another 
 branch?
 
 I committed to AOO400 because I supposed that newer (minor) releases 
 were going into this branch, not into a different one.
 
 And I don't undestand at all why branching again for 401, while we can
 just use tagging to monitor minor bugfixes releases from AOO400 
 branch.
 

we simply preserve the release branch. A branch is cheap in svn and we
can easier differentiate where the fixes should go.

 I understand that a 4.1 release will incorporate new code while we can
 still produce 4.0.2 on the older branch, so branching for 4.1 makes 
 more sense.

well we can of course discuss this further but because the fact that
branches are cheap we can also use this scheme.

 
 with this branching tecnique, a bugfix must be sideported to every 
 active branch, e.g. trunk, AOO401, AOO410 (maybe more in the future).

why? We don't have a 4.1 branch and fixes only have to be merged in a
branch if they are accepted showstopper. Now with the new branch nobody
should work on the AOO400 branch. The branch is dead for further
development.

Work towards 4.1 should happen on trunk. Major features should be done
on a separate branch anyway.

 
 If I missed some guideline doc on the wiki please excuse me.
 

No you don't miss any guideline and again we can discuss it. But it
change nothing. Either AOO400 or AOO401 in both cases you should
integrate only code that are related to an existing issue which is
proposed and accepted as showstopper.

Juergen

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

Re: [RELEASE]: preparation for AOO 4.0.1

On 8/13/13 6:01 PM, Fernando Cassia wrote:
 On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote:
 In preparation for an AOO 4.0.1 release I have first created a AOO400
 tag based on revision 1503704. I have also created a new branch AOO401
 based on branch AOO400 based on the head revision of the branch.

 I noticed that Yuri checked in some code on the branch already. Can we
 please follow some guideline how we handle such release branches?
 
 Is there a chance to get a fix so that AOO 4.0.1 starts properly
 maximized ALL THE TIME?
 
 On Windows at least (Win7 64bit) it didn't. Of course after maximizing
 it, it started maximized after the fact (probably reading the last
 window size from some saved preference, but the fact that it doesn't
 automagically maximize its window annoys me. Is there a bug report for
 this? Anyone else seen this? Any rationale for the app not starting
 maximized?.
 
 On a related note, the first thing I do (since the StarOffice 3.1
 days) when I open a new document is set zoom level to Optimal (or
 optimize width, I'm not sure right now how it's called).
 
 Why isn't this the default is beyond me. Otherwise, with the standard
 zoom level lots of horizontal screen real state is wasted. Thoughts?
 Comments? Expletives? ;)

Probably not, it's mainly your personal preference which is fine. But if
we change it it annoys potentially other users. The question is what
would be the correct and most often wanted default.

These are questions that we can't answer easy. We can run a survey and
will potentially get a 60:40, 70:30 or 50:50 answer that won't help us.

But you can try to figure out the related config item and can create a
mini extension that you deploy in your office to use a different
default. Don't ask me which config item is relevant here, I don't know
without looking into the code.

Juergen

 
 FC
 
 -
 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: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread Rory O'Farrell

On Tue, 13 Aug 2013 12:43:47 -0400
Fernando Cassia fcas...@gmail.com wrote:

 On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt jogischm...@gmail.com 
 wrote:
  But if
  we change it it annoys potentially other users. The question is what
  would be the correct and most often wanted default.
 
 What is the purpose of showing margins, and by extension, seeing text
 smaller, (less zoom level)?. Is there any data the user can put on
 Margins? change the margin colors? put pictures in margins?. In short:
 what use is there for margins taking a sizeable portion of the screen
 size?
 
 I'm not saying we should NOT show margings, after all, in Optimal
 width, a portion of the margins is seen, but not 50-100 pixels of
 them, on every side.
 
 I'm not even saying the view with margins is wrong, maybe someone
 wants to look at the bigger picture. But for TYPING text, optimal
 width is the best. So, again, why isn't that option the default?.
 
 Maybe the UX guys can comment?. And yes, I'd love to see a survey. And
 even better, some telemetry (like Firefox' ) about how many users,
 when typing or browsing text documents, end up viewing the document in
 optimize width mode).
 
 Thanks for taking the time to answer, btw. Appreciate it.
 Best regards,
 
 FC
 -- 
 During times of Universal Deceit, telling the truth becomes a revolutionary 
 act
 - George Orwell

Comments can live on the desktop beyond the right margin setting. Also, the 
margins help one see what the finished page will look like.

-- 
Rory O'Farrell ofarr...@iol.ie

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

Re: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread Ricardo Berlasso

2013/8/13 Fernando Cassia fcas...@gmail.com

 On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt jogischm...@gmail.com
 wrote:
  But if
  we change it it annoys potentially other users. The question is what
  would be the correct and most often wanted default.

 What is the purpose of showing margins, and by extension, seeing text
 smaller, (less zoom level)?. Is there any data the user can put on
 Margins? change the margin colors? put pictures in margins?. In short:
 what use is there for margins taking a sizeable portion of the screen
 size?



I do not see those margin you talk about and for a good reason: I never use
maximized windows. I hate maximized windows. Other people love maximized
windows, of course, but many of us just hate them: how do you count how
many people is on each camp?

Default values are an important discussion point and I started a couple of
threads about defaults in the past, but defaults are also an incredible
difficult question where almost all possible answers are at the same time
wrong and right for someone.

I propose to start (again) a discussion about default values, but not now:
let's concentrate on 4.0.1.

Regards
Ricardo




 I'm not saying we should NOT show margings, after all, in Optimal
 width, a portion of the margins is seen, but not 50-100 pixels of
 them, on every side.

 I'm not even saying the view with margins is wrong, maybe someone
 wants to look at the bigger picture. But for TYPING text, optimal
 width is the best. So, again, why isn't that option the default?.

 Maybe the UX guys can comment?. And yes, I'd love to see a survey. And
 even better, some telemetry (like Firefox' ) about how many users,
 when typing or browsing text documents, end up viewing the document in
 optimize width mode).

 Thanks for taking the time to answer, btw. Appreciate it.
 Best regards,

 FC
 --
 During times of Universal Deceit, telling the truth becomes a
 revolutionary act
 - George Orwell

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

Re: Additional languages for buildbots

2013-08-13 Thread Andrew Rist



On 8/13/2013 1:18 AM, Herbert Duerr wrote:

On 13.08.2013 08:42, Andrea Pescetti wrote:

I see that yesterday's buildbot run completed successfully
http://ci.apache.org/projects/openoffice/#winsnap
(even though, since we are still building the SNAPSHOT tag, running that
buildbot is only testing that the buildbot works). This is the only one
where we support localization at the moment.

Before we forget, can we add to it at least
zh-TW (unsure aoput the right syntax) km pl kid ?
The first 3 languages are 100% complete in Pootle, kid is the KeyID
and it's useful to translators.


I now added km and zh-TW, pl was already there. Enabling the 
keyid build doesn't make sense until [1] is fixed. The current kid 
localization is quite out of date.


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

Excellent - I was going to do this, but Herbert beat me to it.





This is only a step in making the new languages available for testing
(the other two being: regenerating the SDF files and moving the SNAPSHOT
tag or equivalent on the buildbot side), but it is independent of the
other actions needed.

And what is preventing us from having at least one Linux buildbot
equivalent to win7snap? I thought disk space was the issue, but from
Andrew's remarks I understood this is no longer problematic under
Windows or Linux.


Last week we ran out of space on the Windows buildbot. When Andrew 
cleaned things out they started working again. With the additional 
languages we are stressing it a bit more now though.
Actually, the situation is not too bad - the disk space issue is under 
control now and we have space for languages as they become available.


The snapshot tag is currently only moved sporadically so spending time 
in setting up new snapshot buildbots for e.g. Linux is an arguable 
investment.

We are waiting on the CentOS bot to set up the Linux 32 snapshot build.
I'm also about to look at the ubuntu bots - now that they're back on , 
it would be good to have them running through correctly.

For most cases the already existing nightly builds are better.
This is something we need to resolve (by making the bot builds better, 
of course) I think the CentOS bot will help us move in that direction.


Herbert

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




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

Possible broken link: from other.html

2013-08-13 Thread Brad Smith

Re: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread Keith N. McKenna


Kay Schenk wrote:

On Tue, Aug 13, 2013 at 6:26 AM, janI j...@apache.org wrote:


On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote:


On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com
wrote:

Hi,

first if all I volunteer to act as the release manager for AOO 4.0.1 if
that is wanted but I am also open to let somebody else to the job ;-)



It is probably best if you continue, since 4.0.1 is very closely
related to 4.0.0, and you already have the build environment set up,
etc.


+1




In preparation for an AOO 4.0.1 release I have first created a AOO400
tag based on revision 1503704. I have also created a new branch AOO401
based on branch AOO400 based on the head revision of the branch.

I noticed that Yuri checked in some code on the branch already. Can we
please follow some guideline how we handle such release branches?

I would like to propose the following:

Changes on a release branch should be discussed before and should be in
relation to a proposed and approved fix (if you want showstopper) that
will go in the next release.


For now that means the branch AOO400 is dead and changes towards AOO
4.0.1 have to be made on the new branch AOO401 and should be discussed
first. Or propose the related issue as showstopper first.

I believe we agreed more or less to keep the changes for AOO 4.0.1
minimal to reduce the test effort. We should concentrate on the most
serious issues only and on new languages or improved translations. Keep
in mind that AOO 4.1 is coming as well. Stability is a key feature and
every single bug fix can introduce a regression as well. Often not
obvious directly.



I assume we also want to avoid introducing new UI strings?   Otherwise
we'd require translation updates on all languages.



I would formulate it stronger: we cannot allow new strings, unless it is
absolutely unavoidable.






Any opinions or comment son this plan.



Should we create new Release Notes?  Or augment the existing 4.0.0
ones?   It might be simpler if 4.0.x releases share the same release
notes, but we start with fresh ones for 4.1?



Lets share release notes, amend so that is clear what is only available in
4.0.1, and start from a fresh with 4.1



For 3.4.1, which was basically an update release with addtional languages,
the release notes were sort of like an addendum to 3.4.0 --


https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes

I think Release Notes for 4.0.1 should be similar but, yes, we need a new
page for them.


I agree, the release notes for 4.0.1 should have there own page 
documenting the changes for that release only with a link to the full 
4.0.0 notes.


Regards
Keith


I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc.

rgds
jan I.




-Rob


Juergen

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



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











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

Re: [WWW]ES download site broken

2013-08-13 Thread Marcus (OOo)


Am 08/13/2013 12:52 AM, schrieb Andrea Pescetti:

Andrea Pescetti wrote:

Ricardo Berlasso wrote:

I need some urgent help here. I just opened the ES download site and
noticed that there is no download button!
http://www.openoffice.org/es/descargar/

Same for me in
http://www.openoffice.org/it/download/


Both fixed. In short: pages need to include /download/release_matrix.js
now.

If someone else has problems, to fix your download page just follow the
IT and ES fixes:

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/it/download/index.html?r1=1506830r2=1513286diff_format=h


http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/es/descargar/index.html?r1=1508685r2=1513287diff_format=h


It seems my latest changes to show the file size in the green box has 
caused this inconsistency when updating the main download webpage.


I'm very sorry that this caused trouble on your side. I promise to do 
more testing in the future.


If there is anything left just tell me and I'll fix it.

Marcus


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

Re: [RELEASE]: preparation for AOO 4.0.1

2013-08-13 Thread Marcus (OOo)


Am 08/13/2013 06:13 PM, schrieb Kay Schenk:

On Tue, Aug 13, 2013 at 6:26 AM, janIj...@apache.org  wrote:


On 13 August 2013 15:14, Rob Weirrobw...@apache.org  wrote:


On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidtjogischm...@gmail.com
wrote:

Hi,

first if all I volunteer to act as the release manager for AOO 4.0.1 if
that is wanted but I am also open to let somebody else to the job ;-)



It is probably best if you continue, since 4.0.1 is very closely
related to 4.0.0, and you already have the build environment set up,
etc.


+1


I'm fine with another round.


In preparation for an AOO 4.0.1 release I have first created a AOO400
tag based on revision 1503704. I have also created a new branch AOO401
based on branch AOO400 based on the head revision of the branch.

I noticed that Yuri checked in some code on the branch already. Can we
please follow some guideline how we handle such release branches?

I would like to propose the following:

Changes on a release branch should be discussed before and should be in
relation to a proposed and approved fix (if you want showstopper) that
will go in the next release.


For now that means the branch AOO400 is dead and changes towards AOO
4.0.1 have to be made on the new branch AOO401 and should be discussed
first. Or propose the related issue as showstopper first.

I believe we agreed more or less to keep the changes for AOO 4.0.1
minimal to reduce the test effort. We should concentrate on the most
serious issues only and on new languages or improved translations. Keep
in mind that AOO 4.1 is coming as well. Stability is a key feature and
every single bug fix can introduce a regression as well. Often not
obvious directly.



I assume we also want to avoid introducing new UI strings?   Otherwise
we'd require translation updates on all languages.



I would formulate it stronger: we cannot allow new strings, unless it is
absolutely unavoidable.






Any opinions or comment son this plan.



Should we create new Release Notes?  Or augment the existing 4.0.0
ones?   It might be simpler if 4.0.x releases share the same release
notes, but we start with fresh ones for 4.1?



Lets share release notes, amend so that is clear what is only available in
4.0.1, and start from a fresh with 4.1



For 3.4.1, which was basically an update release with addtional languages,
the release notes were sort of like an addendum to 3.4.0 --


https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes

I think Release Notes for 4.0.1 should be similar but, yes, we need a new
page for them.


+1

In general refer to the 4.0.0 release notes and add just the new things. 
The 3.4.1 release notes are a good example.


Marcus




I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc.

rgds
jan I.




-Rob


Juergen


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

unexpected behavior from configure -- new env script not generated

Yesterday, I did a dmake clean to start over with my build, and then
proceded with autoconf and configure. I had chagned my ant version a while
back and this was reflected in my configure call. Much to my surprise, the
old ant version seemed to be stuck' in configure's brain, and it took me a
while to track this down and just delete my existing shell environment
script. Then the configure worked as expected. This was the ONLY change in
my configure params

Any guesses as to the cause of this?
* Is this a problem with *my* system autoconf or configure ?
* is this how things normally work and we should document this in the build
instructions ?

I'm looking at configure.in etc but since I'm not an autoconf guru, well,
what to do.

-- 
-
MzK

Success is falling nine times and getting up ten.
 -- Jon Bon Jovi

Re: Unnecesary filestructure on images

On Tue, Aug 13, 2013 at 2:04 AM, Alexandro Colorado j...@oooes.org wrote:

On Mon, Aug 12, 2013 at 8:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org
wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org wrote:

For example, the new logo, was simply draged and drop to the
AOOLogos
folder with a huge name. I understand the name was needed to
identify
it
between the rest of the competitive logos. But now that is selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0, which
I helped check in.

My intent was to take that SVG and rename it to master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just
incrementally
replace with the future logos as we update the SVG.

No, it shouldn't. The ooo-site/images areas got the logo added to it simply
because to make it easier to locate it. The other images files there belong
to the home page. The svg sub-directory here is really the mis-placed one.

If those complications arises, send them to marketing or branding
workspaces.

svg are just like HTML files, they are markup languages, we dont hold the
index.html inmaculated and hold an apache-index.html and oracle-index.html,
so I dont see why SVG should be any different.

I don't agree this assessment. The svg files contain branding, or
trademark sources. These are entities which should not be changed --
resulting in a trademark violation. If there is something wrong with the
SVG files for whatever reason, this needs to undergo a justification
discussion.

The only porpouse of having
a source file, is for users to be able to modify it on the first place.
Either by integrating to a bigger SVG design, or resizing it for print
work.

This part I do agree with. The svg files can be used to produce various
sizes of the trademarked entities. Changing the source of that entity is
a different matter in my opinion.

Of course you can have a hybrid approach:

1) When a new logo is introduced, svn copy the old one into a
/old-logos directory with a new descriptive name. This preserves the
version history.

Re: unexpected behavior from configure -- new env script not generated

2013-08-13 Thread janI

On 13 August 2013 21:03, Kay Schenk kay.sch...@gmail.com wrote:

 Yesterday, I did a dmake clean to start over with my build, and then
 proceded with autoconf and configure. I had chagned my ant version a while
 back and this was reflected in my configure call. Much to my surprise, the
 old ant version seemed to be stuck' in configure's brain, and it took me a
 while to track this down and just delete my existing shell environment
 script. Then the configure worked as expected. This was the ONLY change in
 my configure params

 Any guesses as to the cause of this?
 * Is this a problem with *my* system autoconf or configure ?
 * is this how things normally work and we should document this in the build

I have had similar problems a couple of times.

I used to have source LinuxX86-64Env.Set.sh in .bashrc, meaning
environment was set when I ran configure.

After having a couple of strange problem (in my case with epm), I took
source... out of .bashrc, so securing that I run configure without the
AOO environment, since then I have not had problems.

Due to my genLang tests, I do configure a couple of times pr week (to test
my build changes).

hope it helps.
rgds
jan I.

instructions ?

 I'm looking at configure.in etc but since I'm not an autoconf guru, well,
 what to do.

 --

 -
 MzK

 Success is falling nine times and getting up ten.
  -- Jon Bon Jovi

Re: Unnecesary filestructure on images

On 8/13/13, Kay Schenk kay.sch...@gmail.com wrote:
On Tue, Aug 13, 2013 at 2:04 AM, Alexandro Colorado j...@oooes.org wrote:

On Mon, Aug 12, 2013 at 8:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org
wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 1:35 AM, Alexandro Colorado j...@oooes.org
wrote:
I think the image structure on the website is a bit messy, there
has
been
some cleanup done by kschenk but I think there is still a lot of
clean up
work to be done.

For example, the new logo, was simply draged and drop to the
AOOLogos
folder with a huge name. I understand the name was needed to
identify
it
between the rest of the competitive logos. But now that is
selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0,
which
I helped check in.

My intent was to take that SVG and rename it to master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just
incrementally
replace with the future logos as we update the SVG.

I think that 'complication' is the lesser of two evils., compared to
having to manage a ever growing ammount of images. And beside that, do
you
realize the difference in objectives between ooo-site/images/
ooo-site/marketing/art/images/ and ooo-site/branding/images.

Then there is also no need for multiple versions of the logo either,
like is currently loaded including the current long filename.

If those complications arises, send them to marketing or branding
workspaces.

svg are just like HTML files, they are markup languages, we dont hold the
index.html inmaculated and hold an apache-index.html and
oracle-index.html,
so I dont see why SVG should be any different.

If we go by that scenario, every footer, about page also contain
trademark information, that shouldnt be modified.

The only porpouse of having
a source file, is for users to be able to modify it on the first place.
Either by integrating to a bigger SVG design, or resizing it for print
work.

This part I do agree with. The svg files can be used to produce various
sizes of the trademarked entities. Changing the source of that entity is
a different matter in my opinion.

Of course you can have a hybrid approach:

1) When a new logo is introduced, svn copy the old one into a

AOO SDK

2013-08-13 Thread Bob Helen

Is the subject add-on available for Apache OpenOffice 4?

I can't find [and install] it.

Re: Unnecesary filestructure on images

On 8/13/13, Kay Schenk kay.sch...@gmail.com wrote:
On Tue, Aug 13, 2013 at 2:04 AM, Alexandro Colorado j...@oooes.org wrote:

On Mon, Aug 12, 2013 at 8:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org
wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 1:35 AM, Alexandro Colorado j...@oooes.org
wrote:
I think the image structure on the website is a bit messy, there
has
been
some cleanup done by kschenk but I think there is still a lot of
clean up
work to be done.

For example, the new logo, was simply draged and drop to the
AOOLogos
folder with a huge name. I understand the name was needed to
identify
it
between the rest of the competitive logos. But now that is
selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0,
which
I helped check in.

My intent was to take that SVG and rename it to master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just
incrementally
replace with the future logos as we update the SVG.

I think that 'complication' is the lesser of two evils., compared to
having to manage a ever growing ammount of images. And beside that, do
you
realize the difference in objectives between ooo-site/images/
ooo-site/marketing/art/images/ and ooo-site/branding/images.

Actually I would like to see getting rid of the rasterize images
instead. Modern browsers already process SVG natively without issues.
Also there are js libraries that ensure browser compatibility like the
svgweb.js library:
http://code.google.com/p/svgweb/

If those complications arises, send them to marketing or branding
workspaces.

svg are just like HTML files, they are markup languages, we dont hold the
index.html inmaculated and hold an apache-index.html and
oracle-index.html,
so I dont see why SVG should be any different.

The only porpouse of having
a source file, is for users to be able to modify it on the first place.
Either by integrating to a bigger SVG design, or resizing it for print
work.

This part I do agree with. The svg files can be used to produce various
sizes of the trademarked entities. Changing the source of that entity is
a different matter in my opinion.

Of course you can have a hybrid approach:

1) When a new logo is introduced, svn copy the old one

Re: Unnecesary filestructure on images

On Tue, Aug 13, 2013 at 12:51 PM, Alexandro Colorado j...@oooes.org wrote:

On 8/13/13, Kay Schenk kay.sch...@gmail.com wrote:
On Tue, Aug 13, 2013 at 2:04 AM, Alexandro Colorado j...@oooes.org
wrote:

On Mon, Aug 12, 2013 at 8:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org
wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org
wrote:

On Sun, Aug 11, 2013 at 1:35 AM, Alexandro Colorado j...@oooes.org

wrote:
I think the image structure on the website is a bit messy, there
has
been
some cleanup done by kschenk but I think there is still a lot of
clean up
work to be done.

For example, the new logo, was simply draged and drop to the
AOOLogos
folder with a huge name. I understand the name was needed to
identify
it
between the rest of the competitive logos. But now that is
selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0,
which
I helped check in.

My intent was to take that SVG and rename it to
master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just
incrementally
replace with the future logos as we update the SVG.

I think that 'complication' is the lesser of two evils., compared to
having to manage a ever growing ammount of images. And beside that, do
you
realize the difference in objectives between ooo-site/images/
ooo-site/marketing/art/images/ and ooo-site/branding/images.

I dont see any reason why those issues should impact the web works of
ooo-site/images/. That folder is for website-design related work. It
has,
or shouldnt hold any porpouse to archieve past work, nor to hold
description of any kind. I think website should be as lean and easy to
follow since we expect these conventions be followed by a rotating
community. So again K.I.S.S.

No, it shouldn't. The ooo-site/images areas got the logo added to it
simply
because to make it easier to locate it. The other images files there
belong
to the home page. The svg sub-directory here is really the mis-placed
one.

Then there is also no need for multiple versions of the logo either,
like is currently loaded including the current long filename.

If those complications arises, send them to marketing or branding
workspaces.

svg are just like HTML files, they are markup languages, we dont hold
the
index.html inmaculated and hold an apache-index.html and
oracle-index.html,
so I dont see why SVG should be any different.

If we go by that scenario, every footer, about page also contain
trademark information, that shouldnt be modified.

True enough and we generally discuss anything like that before making
changes.

The only porpouse of having
a source file, is for users to be able to modify it on the first place.
Either by integrating to a bigger SVG design, or resizing it for print
work.

This

Re: Unnecesary filestructure on images

On Tue, Aug 13, 2013 at 1:29 PM, Alexandro Colorado j...@oooes.org wrote:

On 8/12/13, Kay Schenk kay.sch...@gmail.com wrote:
On Mon, Aug 12, 2013 at 6:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org
wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 1:35 AM, Alexandro Colorado j...@oooes.org
wrote:
I think the image structure on the website is a bit messy, there
has
been
some cleanup done by kschenk but I think there is still a lot of
clean up
work to be done.

For example, the new logo, was simply draged and drop to the
AOOLogos
folder with a huge name. I understand the name was needed to
identify
it
between the rest of the competitive logos. But now that is
selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0, which
I helped check in.

My intent was to take that SVG and rename it to master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just
incrementally
replace with the future logos as we update the SVG.

Of course you can have a hybrid approach:

1) When a new logo is introduced, svn copy the old one into a
/old-logos directory with a new descriptive name. This preserves the
version history.

2) New logo then is checked in as a new revision of logo-master.svg.

I like this idea or something akin to it. We should definitely preserve
svgs for old logos in my opinion. The new branding repository can be

Why are you multiplicating image repositories, where Art already has
one with the whole image structure clasified and versioned?

I'm putting the sources into the branding source area, We had already
discussed this. Soon we will probably discuss deleting them *from* the
marketing/art area. The biggest problem right now is actually FINDING all
these.

For now, there will be some duplications.

Apache OpenOffice does not have the same structure as the old
OpenOffice.org with defined project areas, project area leaders, project
area committers etc. So setting up the separate branding area was
discussed and these files are now being put there.

used for this, and given some additional structure. I'm also finding
some
svg masters for items that are not really logos, like Get It Here, that
probably need to be moved to branding even though they are not really
logos.

And, because there are quite a few sites using old logo versions, I don't
really think we should track them all down and require them to upgrade.

Again, I am only referring to svg for these. Renderings, png files, as
far
as I'm concerned, can be renamed and kept anywhere. The new logo used on
the website now, for example, is not a drop in replacement for the old
one, because the size is slightly larger due to design considerations.
So,
it's conceivable, depending on use, the even within the Apache OpenOffice
site, etc., different renderings might be used. But maybe this is in
opposition to what marketing folks mean by a logo with a specific size,
etc., I don't know.

Regards,

-Rob

or something clean like that. However, I have not had any luck
getting this logo to load into Inkscape or Adobe Illustrator. I get
errors. And I have

Re: Unnecesary filestructure on images

On 8/13/13, Kay Schenk kay.sch...@gmail.com wrote:
On Tue, Aug 13, 2013 at 12:51 PM, Alexandro Colorado j...@oooes.org wrote:

On 8/13/13, Kay Schenk kay.sch...@gmail.com wrote:
On Tue, Aug 13, 2013 at 2:04 AM, Alexandro Colorado j...@oooes.org
wrote:

On Mon, Aug 12, 2013 at 8:25 AM, Rob Weir robw...@apache.org wrote:

On Sun, Aug 11, 2013 at 7:49 PM, Alexandro Colorado j...@oooes.org
wrote:
On Sun, Aug 11, 2013 at 6:33 PM, Rob Weir robw...@apache.org
wrote:

On Sun, Aug 11, 2013 at 1:35 AM, Alexandro Colorado
j...@oooes.org

wrote:
I think the image structure on the website is a bit messy,
there
has
been
some cleanup done by kschenk but I think there is still a lot
of
clean up
work to be done.

For example, the new logo, was simply draged and drop to the
AOOLogos
folder with a huge name. I understand the name was needed to
identify
it
between the rest of the competitive logos. But now that is
selected,
the
current name is unecessary long.

Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png

http://svn.apache.org/viewvc/openoffice/ooo-site/trunk/content/images/AOO_logos/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_optim_300w.png?view=log

Right. That work is incomplete. I checked it in originally,
after
the logo vote, so we could start working on the product
integration
immediately. But note that the above logo is not the one we
actually
used in AOO 4.0 !!

The one we actually used is this one:

https://svn.apache.org/repos/asf/openoffice/branding/Apache_OpenOffice_Logo_ChrisR_selected_2013-06_Inkscape_kg.svg

This was Chris R's contest logo with some minor technical
changes.
Kevin G. used this and generated the PNG/JPG files for AOO 4.0,
which
I helped check in.

My intent was to take that SVG and rename it to
master-logo-40.svg

Again I think we do need a convention for a logo.svg as opposed
to
ending with a logo-30.svg logo-40.svg logo-50.svg. An just
incrementally
replace with the future logos as we update the SVG.

Here's the complication: The old logos are still relevant some
some
purposes. For example, the PMC receives ongoing requests to approve
use of the old OpenOffice.org logo. Why would that happen? Often
it
is a request by publishers who are making an e-book version of an
older print book. If their original request did not include the
e-book rights then they come back to us (and owners of every other
image they use) to request additional permissions.

I think that 'complication' is the lesser of two evils., compared to
having to manage a ever growing ammount of images. And beside that, do
you
realize the difference in objectives between ooo-site/images/
ooo-site/marketing/art/images/ and ooo-site/branding/images.

I dont see any reason why those issues should impact the web works of
ooo-site/images/. That folder is for website-design related work. It
has,
or shouldnt hold any porpouse to archieve past work, nor to hold
description of any kind. I think website should be as lean and easy to
follow since we expect these conventions be followed by a rotating
community. So again K.I.S.S.

No, it shouldn't. The ooo-site/images areas got the logo added to it
simply
because to make it easier to locate it. The other images files there
belong
to the home page. The svg sub-directory here is really the mis-placed
one.

Then there is also no need for multiple versions of the logo either,
like is currently loaded including the current long filename.

If those complications arises, send them to marketing or branding
workspaces.

So it may be possible, going forward, to store logos as SVN
revisions
under the same name. But we cannot retroactively do this with
pre-Apache logos. And even if we could, this is harder for users of
the logo to access. It is much easier to have something like
logo-330.svg available via HTTP.

svg are just like HTML files, they are markup languages, we dont hold
the
index.html inmaculated and hold an apache-index.html and
oracle-index.html,
so I dont see why SVG should be any different.

I don't agree this assessment. The svg files contain branding, or
trademark sources. These are entities which should not be changed --
resulting in a trademark violation. If there is something wrong with
the
SVG files for whatever reason, this needs to undergo a justification
discussion.

If we go by that scenario, every footer, about page also contain
trademark information, that shouldnt be modified.

True enough and we generally discuss anything like that before making
changes.

AFAIK we are doing this right now, and you are already making changes.

The only porpouse of

Re: AOO SDK