date:20120601

On Sat, Jun 2, 2012 at 11:40 AM, Dave Fisher  wrote:
> I am unsure from your statement Choi (is it proper to use the second name in 
> conversation?) whether you were confirming the user's report.
>
It's simple. I installed AOO 3.4 and I realized there's no option for
choosing file association.
I read every sentences on each dialogue box, but there's no mention or
no option.

I installed AOO 3.4 again on another computer. It's on Windows XP and
there is MS Office 2007.
After I installed AOO 3.4, .docx, .xls, .xlsx are opened in MS Office.
However .doc is opened in AOO.
And as I said there was no option nor mention about file association
while installing AOO.
I can't check what exactly happened in registry because I don't have a
authority for that, but I'm
sure AOO changed something without user's agreement or notice.

> The check must not be implicit to the user who just clicks continue and 
> accept buttons through the WIndows installation process. Users must 
> explicitly choose to have AOO override MS Office for MS Office documents.
>
I totally agree with you, dave. and this one should go to bugzilla.

-- 
Regards,
JiHui Choi

Re: The reason I removed the program called Open Office 3.4

2012-06-01 Thread Dave Fisher

On Jun 1, 2012, at 7:18 PM, Jihui Choi wrote:

> On Sat, Jun 2, 2012 at 10:56 AM, Alexandro Colorado  wrote:
>> When you install it you agreed to open doc files in OpenOffice
>> 
> Basically installing AOO doesn't mean we agreed to open MS office
> formats in AOO.
> And it's supposed there's an option page to choose whether we'll open
> them in AOO or not.
> But I couldn't find any similar option. I installed AOO 3.4 twice to
> check this on Windows 7 32bit.
> It's very strange and shame. It should be checked and fixed.

I am unsure from your statement Choi (is it proper to use the second name in 
conversation?) whether you were confirming the user's report.

If what the reporter says is true then this needs to be a bugzilla and possible 
blocker for 3.4.1. How is this being tested on Windows? And is the result that 
installing AOO 3.4 on it does in fact cause (or even has as a default) the 
shifting of MS Office document types to be opened with AOO instead of MS 
Office. If MS Office is present then this must not be the the default option.

The check must not be implicit to the user who just clicks continue and accept 
buttons through the WIndows installation process. Users must explicitly choose 
to have AOO override MS Office for MS Office documents.

Regards,
Dave

> 
> -- 
> Regards,
> JiHui Choi

Re: The reason I removed the program called Open Office 3.4

2012-06-01 Thread Alexandro Colorado

This is normal behavior on EVERY software. If you install firefox a
dialog of "You want to make firefox your default browser" as you
install. Same in Chrome and any other software. Winzip, iTunes, etc.


On Fri, Jun 1, 2012 at 9:18 PM, Jihui Choi  wrote:
> On Sat, Jun 2, 2012 at 10:56 AM, Alexandro Colorado  wrote:
>> When you install it you agreed to open doc files in OpenOffice
>>
> Basically installing AOO doesn't mean we agreed to open MS office
> formats in AOO.
> And it's supposed there's an option page to choose whether we'll open
> them in AOO or not.
> But I couldn't find any similar option. I installed AOO 3.4 twice to
> check this on Windows 7 32bit.
> It's very strange and shame. It should be checked and fixed.
>
> --
> Regards,
> JiHui Choi

Re: The reason I removed the program called Open Office 3.4

On Sat, Jun 2, 2012 at 10:56 AM, Alexandro Colorado  wrote:
> When you install it you agreed to open doc files in OpenOffice
>
Basically installing AOO doesn't mean we agreed to open MS office
formats in AOO.
And it's supposed there's an option page to choose whether we'll open
them in AOO or not.
But I couldn't find any similar option. I installed AOO 3.4 twice to
check this on Windows 7 32bit.
It's very strange and shame. It should be checked and fixed.

-- 
Regards,
JiHui Choi

Re: The reason I removed the program called Open Office 3.4

2012-06-01 Thread Alexandro Colorado

When you install it you agreed to open doc files in OpenOffice

On 6/1/12, Felix Brown  wrote:
> The reason I removed the program called Open Office 3.4 was:
> Today the automatic update to 3.4 happened.
> Today I opened a WordPad file, (Which I open often; It's my list of
> birthdays.);
> And to my surprise, Your piece of junk software had hijacked all of my
> documents
> to where they open with Open Office ; AND THAT SURE AS HECK WAS NOT A CHOICE
> THAT I MADE.
>
>
> I hate programs that act like a virus.
> Fix this ; Then tell me, (IN PERSON, BY EMAIL OF PHONE.) ; And then, MAYBE
> I'LL
> REINSTALL IT.
>
>
> Felix Brown
> 316 722-3744
> buy-a-thing-or-...@sbcglobal.net


-- 
Alexandro Colorado
OpenOffice.org Español
http://es.openoffice.org

The reason I removed the program called Open Office 3.4

2012-06-01 Thread Felix Brown

The reason I removed the program called Open Office 3.4 was:  
Today the automatic update to 3.4 happened. 
Today I opened a WordPad file, (Which I open often; It's my list of 
birthdays.); 
And to my surprise, Your piece of junk software had hijacked all of my 
documents 
to where they open with Open Office ; AND THAT SURE AS HECK WAS NOT A CHOICE 
THAT I MADE. 


I hate programs that act like a virus. 
Fix this ; Then tell me, (IN PERSON, BY EMAIL OF PHONE.) ; And then, MAYBE I'LL 
REINSTALL IT. 


Felix Brown 
316 722-3744 
buy-a-thing-or-...@sbcglobal.net

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)


Sorry to highlight something more here...

The draft (which I insist is clearer that the resolved FAQ)
says, under License Categories:

http://www.apache.org/legal/3party.html#criteriaandcategories

/"Even optional works must adhere to this policy if they are included as 
part of the Apache product."/


So even when Category B tarballs appear to be optional,
in practice they are part of the product and we shouldn't
be distributing source code.

cheers,

Pedro.

On 06/01/12 20:08, Pedro Giffuni wrote:

Hi Ross;

I don't think it's "my turn" since my issues remain unresolved.

However let me recap:

1) I think just having patches that can or cannot be applied
to category-B licensed code is OK as long as it is not the
default.

2) I don't think we are allowed to distribute source tarballs
in subversion. The argument in the legal FAQ would seem
not to be specific enough:
http://www.apache.org/legal/resolved.html#category-b

" Software under the following licenses may be included in binary form 
within an Apache

product if the inclusion is appropriately labeled"

Redistribution of Category B in small quantities is also permitted but
both clarifications clearly imply including source code the size and
complexity of Mozilla Seamonkey is prohibited.

The draft on which the policy was based is very clear:
http://www.apache.org/legal/3party.html#criteriaandcategories

"Although the source must not be included in Apache products, the 
NOTICE file, which is required to be included in each ASF 
distribution,*must point to thesource 
form of the 
included binary*(more on that in the forthcoming "Receiving and 
Releasing Contributions" document)."


I don't think anyone is arguing here that the principle has changed and
that we can include Category-B software

3) EPL and other licenses state that we must point to the source code
used to generate the binary and this has already been pointed out by
external developers like the COIN-OR guys.

We are currently carrying outdated versions of Seamonkey
and saxon in SVN and we are unable to point to the sources due
to 2 reasons:

1) The specific source code is not available upstream anymore.

2) If the code is enabled (which is the default in the buildbots),
the specific source code is patched during the build.
I sustain that by keeping these sources in our SVN tree
we are for all purposes forking the code and to some extent
becoming the new upstream maintainers. Even if the original
code is available upstream I still don't see a good reason
to carry that code under version control.

4) I can't find a precedent among any other Apache Project
where the ASF distributes Category-B sources in SVN, so I
think hosting them would require a specific approval by
legal@.

My understanding is that there is work being done to have
these issues solved on Monday.

Pedro.


On 06/01/12 18:09, Ross Gardler wrote:

Just bringing this item back to the top. Nobody has linked to a policy
that allows this or disallows it yet. However, Pedro has indicated he
doesn't object to this specific case.

Can we consider this one done? If so that is good progress (thank you
Jurgen for making consensus possible on one specific case).

Lets move onto the next one. Pedro raised a concern about a specific
case and, if I'm following right there isn't consenus on that one (I
wouldn't be surprised if I'm not following right since I'm tired of
reading the arguments that go round in circles and stopped as soon as
it descended again into non-specific cases).

Can we have an equally detailed and clear description about the case
Pedro highlights? We only need the facts about the problem being
solved and the current solution, not the arguments for/against. Pedro,
I suggest it's your turn since Jurgen started the ball rolling, Rob
can be up next (sorry to sound like a school teacher, please think of
me as a conductor not a school teacher - I'm not trying to patronise,
it's just it's very late here and I still have a client deliverable
that AOO has stood in the way of for the last two days).

Once we have the facts laid out nice and cleanly lets seek pointers to
policy that allows or disallows the solution in place. If pointers are
not possible lets take the specific case to the IPMC for
clarification.

Ross

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)


Hi Ross;

I don't think it's "my turn" since my issues remain unresolved.

However let me recap:

1) I think just having patches that can or cannot be applied
to category-B licensed code is OK as long as it is not the
default.

2) I don't think we are allowed to distribute source tarballs
in subversion. The argument in the legal FAQ would seem
not to be specific enough:
http://www.apache.org/legal/resolved.html#category-b

" Software under the following licenses may be included in binary form 
within an Apache

product if the inclusion is appropriately labeled"

Redistribution of Category B in small quantities is also permitted but
both clarifications clearly imply including source code the size and
complexity of Mozilla Seamonkey is prohibited.

The draft on which the policy was based is very clear:
http://www.apache.org/legal/3party.html#criteriaandcategories

"Although the source must not be included in Apache products, the NOTICE 
file, which is required to be included in each ASF distribution,*must 
point to thesource 
form of the 
included binary*(more on that in the forthcoming "Receiving and 
Releasing Contributions" document)."


I don't think anyone is arguing here that the principle has changed and
that we can include Category-B software

3) EPL and other licenses state that we must point to the source code
used to generate the binary and this has already been pointed out by
external developers like the COIN-OR guys.

We are currently carrying outdated versions of Seamonkey
and saxon in SVN and we are unable to point to the sources due
to 2 reasons:

1) The specific source code is not available upstream anymore.

2) If the code is enabled (which is the default in the buildbots),
the specific source code is patched during the build.
I sustain that by keeping these sources in our SVN tree
we are for all purposes forking the code and to some extent
becoming the new upstream maintainers. Even if the original
code is available upstream I still don't see a good reason
to carry that code under version control.

4) I can't find a precedent among any other Apache Project
where the ASF distributes Category-B sources in SVN, so I
think hosting them would require a specific approval by
legal@.

My understanding is that there is work being done to have
these issues solved on Monday.

Pedro.


On 06/01/12 18:09, Ross Gardler wrote:

Just bringing this item back to the top. Nobody has linked to a policy
that allows this or disallows it yet. However, Pedro has indicated he
doesn't object to this specific case.

Can we consider this one done? If so that is good progress (thank you
Jurgen for making consensus possible on one specific case).

Lets move onto the next one. Pedro raised a concern about a specific
case and, if I'm following right there isn't consenus on that one (I
wouldn't be surprised if I'm not following right since I'm tired of
reading the arguments that go round in circles and stopped as soon as
it descended again into non-specific cases).

Can we have an equally detailed and clear description about the case
Pedro highlights? We only need the facts about the problem being
solved and the current solution, not the arguments for/against. Pedro,
I suggest it's your turn since Jurgen started the ball rolling, Rob
can be up next (sorry to sound like a school teacher, please think of
me as a conductor not a school teacher - I'm not trying to patronise,
it's just it's very late here and I still have a client deliverable
that AOO has stood in the way of for the last two days).

Once we have the facts laid out nice and cleanly lets seek pointers to
policy that allows or disallows the solution in place. If pointers are
not possible lets take the specific case to the IPMC for
clarification.

Ross

Re: [PROPOSAL] Starting the graduation process

2012-06-01 Thread Peter Junge


On 5/30/2012 12:13 AM, Rob Weir wrote:

On Tue, May 29, 2012 at 11:42 AM, Yong Lin Ma  wrote:


[...]


Are there any contributions yet from C2SC?  If there are, then by all
means, review them and if they are of good quality, then propose them
for becoming committers.  It would be a graduation issue if we had
volunteers making sustained contributions but we failed to make them
committers.  That would mean we were not open.  But I don't see that
happening.



I just found that we already have a PPMC member from CS2C. An Hongyun 
joined us from the beginning while she was still working for RedFlag 2000.


An Hongyun,
looks like you have an important role now. I'm convinced you will do it 
good.


Peter

Re: Bring back the distributors page!

2012-06-01 Thread Peter Junge


On 6/2/2012 3:30 AM, Donald Whytock wrote:

On Fri, Jun 1, 2012 at 3:00 PM, John Schmidt  wrote:

I thought this was a great idea and have always had my software up to date
and delivered on time. I can't say anything for anyone else, but my site
looks professional and I also supply the buyer with choices of support
packages. I for one would like this to stay open. I have not received a sale
since the switch to Apache Openoffice. So if you can please bring the
distributors page back.


Perhaps a user forum thread for service suppliers would be better than
a webpage.  A webpage has to be maintained and can have links that are
out of date, whereas a forum thread is more dynamic and would seem
more up-to-date.


The message was moderated, not by me, hence this reply might not reach John.

Furthermore, his email address might be considered misleading. Thoughts? 
Apache policies?


Peter

Re: ODF Command Line Tools -- Request for community feedback

2012-06-01 Thread Noah Tilton

Rob,

I have thoroughly investigated Maven.  It is not immediately clear to
me how one would use Maven for a jruby project.  Apache Buildr seems a
better fit, but in my view neither is as easy as it should be.  And
whether we use Maven or buildr or $X, people will still have to
manually install jruby.

I'm not saying we can't/shouldn't use a build tool, just that I spent
way too much time this week fighting to make one work and failed
miserably.

So, I wrote a very simple (20-line) bash script which downloads jars
and sets local shell variables, to make the example I sent to you
previously work.  As long as you have wget, java, and jruby installed,
you should be able to run

% ./test.sh

And see an immediate working result.  If that is not the case, please
let me know.

https://github.com/noah/odf-command-line-tools

My plan is to get the DSL working and worry about making the build
scripts pretty later.  If it works with standard Linux tools, that
should be doable.  Please let me know your thoughts.

Thanks,
-Noah

On Tue, May 29, 2012 at 3:50 AM, Rony G. Flatscher (Apache)
 wrote:
>
> On 5/29/2012 3:49 AM, Fernando Cassia wrote:
>> On Mon, May 28, 2012 at 4:21 PM, Rob Weir  wrote:
>>
>>> For example, does
>>> JRuby pre-req a JDK version?
>>>
>>> -Rob
>>>
>> I am 100% sure it runs both on the propietary Java one gets from java.com,
>> (1.6 onwards, including JDK7) and also on OpenJDK (1.7 here on Linux).
>>
>> I know because I have run JRuby on both. It' s safe to say JRE or JDK 1.6
>> or higher is a requirement. All previous Java versions are EOL' d.
> If possible at all, the base line support should be Java 1.4 as long as 
> possible as there are still
> quite a few Java deployments at that level (also 1.5) in the market despite 
> Sun/Oracle putting the
> EOL death spell on Java 1.4 and 1.5. (Of course, support for 1.4 can only be 
> granted, if it is
> possible to compile the ODF toolkit for target 1.4 and not using Java methods 
> only available in Java
> 1.5 or higher, as 
>  
> mandates
> 1.5 as a minimum JDK level.)
>
> ---rony
>

-- 
Noah

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

2012-06-01 Thread Kay Schenk




On 06/01/2012 01:40 PM, Martin Srebotnjak wrote:

Hello,

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

Lp, m.



Martin --

Thank you very much!

--

MzK

"So let it rock, let it roll
Let the bible belt come and save my soul
Hold on to sixteen as long as you can
Changes come around real soon make us woman and men."
  -- "Jack and Diane", John Mellencamp

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

Just bringing this item back to the top. Nobody has linked to a policy
that allows this or disallows it yet. However, Pedro has indicated he
doesn't object to this specific case.

Can we consider this one done? If so that is good progress (thank you
Jurgen for making consensus possible on one specific case).

Lets move onto the next one. Pedro raised a concern about a specific
case and, if I'm following right there isn't consenus on that one (I
wouldn't be surprised if I'm not following right since I'm tired of
reading the arguments that go round in circles and stopped as soon as
it descended again into non-specific cases).

Can we have an equally detailed and clear description about the case
Pedro highlights? We only need the facts about the problem being
solved and the current solution, not the arguments for/against. Pedro,
I suggest it's your turn since Jurgen started the ball rolling, Rob
can be up next (sorry to sound like a school teacher, please think of
me as a conductor not a school teacher - I'm not trying to patronise,
it's just it's very late here and I still have a client deliverable
that AOO has stood in the way of for the last two days).

Once we have the facts laid out nice and cleanly lets seek pointers to
policy that allows or disallows the solution in place. If pointers are
not possible lets take the specific case to the IPMC for
clarification.

Ross

On 1 June 2012 11:09, Jürgen Schmidt  wrote:
> Hi,
>
> sorry for top posting but I followed Ross advice and will give a
> concrete example.
>
> Hunspell -> MPL + LGPL
>
> - we use currently version 1.2.9 and compile the source in our build env
> on demand when the correct configure switch is used
>
> - we apply 4 or in case of mingw 5 patch files (depends on the mechanism
> that is used in our build env generally for this kind of things)
>
> 3 of these patch files contains minor changes used/necessary for our
> build env.
>
> For example hunspell-solaris.patch:
> ###
> --- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx     2010-02-27
> 23:42:05.0 +
> +++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx    2010-02-27
> 23:43:02.0 +
> @@ -10,6 +10,9 @@
>  #include "hunspell.hxx"
>  #include "csutil.hxx"
>
> +// switch off iconv support for tests (fixing Solaris problems)
> +#undef HAVE_ICONV
> +
>  #ifndef HUNSPELL_EXTRA
>  #define suggest_auto suggest
>  #endif
> ###
>
> One patch apply a back port patch for an important issue that is fixed
> in a newer version. Don't ask me why we haven't upgraded the version
> already. But that is as I mentioned before on our plan.
>
> hunspell-stackmash.patch
> ###
> --- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx       2010-03-04
> 10:25:06.0 +
> +++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
> 10:25:38.0 +
> @@ -1665,7 +1665,7 @@
>   if (!q2) return 0; // bad XML input
>   if (check_xml_par(q, "type=", "analyze")) {
>       int n = 0, s = 0;
> -      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
> analyze(slst, cw);
> +      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
> analyze(slst, cw);
>       if (n == 0) return 0;
>       // convert the result to ana1ana2 format
>       for (int i = 0; i < n; i++) s+= strlen((*slst)[i]);
> @@ -1686,13 +1686,13 @@
>       (*slst)[0] = r;
>       return 1;
>   } else if (check_xml_par(q, "type=", "stem")) {
> -      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
> stem(slst, cw);
> +      if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
> stem(slst, cw);
>   } else if (check_xml_par(q, "type=", "generate")) {
> -      int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
> +      int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
>       if (n == 0) return 0;
>       char * q3 = strstr(q2 + 1, "       if (q3) {
> -        if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN)) {
> +        if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
>             return generate(slst, cw, cw2);
>         }
>       } else {
> ###
>
> This fix is fixed upstream in version 1.2.11, see
> http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell/hunspell.cxx?r1=1.8&r2=1.9
>
>
> That means with our further ongoing improvements in this area we get rid
> of this patch and have only minor patches for our build env.
>
> Building these libs on demand in our build env is for convenience.
> Otherwise we would have to put them somewhere else, have to duplicate
> the build env or would need to build them with our build env and use the
> binary libraries from there. That would mean a further huge burden to
> make the development for AOO more complicate.
>
> I hope this helps
>
> Juergen
>
>
> On 6/1/12 11:07 AM, Ross Gardler wrote:
>> On 1 June 2012 09:50, Jürgen Schmidt  wrote:
>>> On 6/1/12 9:47 AM, Ross Gardler wrote:
 Sent from my mobile device, please forgive errors and brevity.
 On May 31, 2012 5:26 PM, "Pedro G

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service

2012-06-01 Thread Andrea Pescetti


On 01/06/2012 Oliver-Rainer Wittmann wrote:

On 01.06.2012 15:09, Rob Weir wrote:

Also, if we follow Andrea's proposal, we don't link to the NL home
page, but to the NL's download page directly. (If I understand
correctly).

Ok, I will update it.


Both http://www.openoffice.org/it/ and the current one 
http://www.openoffice.org/it/download would do; the latter is much 
uglier since CSS were not imported correctly with the relocation to Apache.



For example, Spanish upgrade URL would be:
http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade

I will check for the Italian download page for our first phase next week.


We can see if we manage to refresh http://www.openoffice.org/it/download 
in a way similar to the Spanish page in the meantime (no problem if it 
is not yet available as a template localizable via mdtext; we can likely 
just grab the HTML from the Spanish site for the time being).


Thanks Roberto for offering to help with the landing pages; maybe we can 
discuss what to write/put in the right hand column, see the Spanish 
example at

http://www.openoffice.org/es/descargar/index.html
and the existing links at
http://www.openoffice.org/it/download/3.4.0/download340.html

Regards,
  Andrea.

[UX] The Questions for users

2012-06-01 Thread Albino B Neto

Hi.

Questions relating to research!

We aren't in order to adjust.

Sorry long text.

Legend:
- Questions
-->Response options.

***
- How old are you ?

- What S.O you use ?
-->Linux
-->Mac
-->Windows
-->other [what]

- Use of Linux ? Wich graphic interface:
-->GNOME
-->KDE
-->Lxde
-->Others [what]

- Where do you use Apache OpenOffice?
-->Home
-->Office
-->Company
-->Telecenter
-->Others [whatl]

-Where to get support ?
-->Manuals
-->Mailling list
-->Search
-->Friends
-->Others [what]

-Where do you want to get support ?
-->Manuals
-->Mailing list
-->Search
-->Friends
-->Others [whatl]

-How often do you use Apahce OpenOffice ?
-->Sometimes
-->With frequency
-->Daily

- How much time you spend on the computer ?
-->30 min to 1 hora
-->1h to 3h
-->3h to 5h
-->More of 8h

- As you consider using the computer ?
-->Beginner
-->intermediate
-->Advanced (expert)

-How important computer for you:
-->unimportant
-->insignificant
-->Very Important

-How do you consider a nice software?
-->With enough buttons
-->Buttons significant
-->Buttons simple and agile
-->Results
-->Buttons and good visual meanings.
***

Accepted reviews and more questions.

Albino

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)


--- Ven 1/6/12, Rob Weir  ha scritto:
...
> >
> > And computers need electricity, which is not free and
> > not available under a compatible license. I wish you
> > could keep focused or at least do an effort to
> > understand the issues so we can solve them.
> >
> 
> Be nice.
> 

Couldn't resist :-P. But I really think you can
bring more intelligent arguments to the discussion
if you focus more on solvig the issues and less on
making your point.

> > The tarball release must be consistent; we cannot hide
> > tarballs in SVN. Creating a directory with the
> Category-A
> > tarballs that form a base of the release along with
> the
> > base distribution is not really a problem. Some of
> them
> > are not available upstream anymore.
> >
> 
> That is one possible technique.  But not the only
> one.  I'm a committer on another Apache project,
> the ODF Toolkit, and we do not include any of the
> dependencies in our release, not even other
> category-a ones.

Well I am a committer in the only big UNIX-like
distribution that is carrying Apache OpenOffice
nowadays. We would really like to use a source
distribution through ASF mirrors but since the ASF
doesn't provide one that works well we have been
rolling our own. Having a working source
distribution would help attract linux packagers,
I think.

Perhaps you happen to have data about how many
people are finding the current source
distribution tarballs useful?

> All of them are downloaded on the fly
> from a central repository.  That is the
> beauty of Maven.
> 

I have personal experience packaging stuff
and this is undesirable. One of my ports
was rejected recently because its inconvenient
to have the buildbot depend on network access.

Pedro.

Re: Friendly Web www.OOoNinja.com

2012-06-01 Thread Andrea Pescetti


On 01/06/2012 drew wrote:

IMO - the individual supporter sites were and are a very real asset.


Yes. And OOo Ninja used to have excellent articles about the new 
OpenOffice features. See for example

http://www.oooninja.com/2009/01/openofficeorg-31-new-features.html

Now, I wish we had had something like that for OpenOffice 3.4... We 
managed to put together very comprehensive and readable release notes, 
but users would still benefit from a quick overview like that one.


Regards,
  Andrea.

Re: Bring back the distributors page!

2012-06-01 Thread Donald Whytock

Not a committer here, but I've been following the list, and have seen
much kvetching about pages containing outdated, inoperable and/or
fraudulent links to outside sites, and how much trouble it is to go
through them and clean out the trash.

It may be helpful to people who want to buy support services for OO,
but it's also a burden to the people who maintain the site, and little
to no burden at all to a service vendor who places a link on the site
and then goes out of business.

Starting with a clean page at this point would simply mean the problem
will come up again later.

I know this is introducing work, but I'd like to make a suggestion: a
distributor sign-up form that accepts a name, a link, an email address
and a text blurb.  Sign-ups get stored in a database and await review.
 The distributor page is either generated dynamically each time or is
re-generated every night, from the database entries that have been
reviewed and approved.

Sign-ups should have timestamps, and should only last for X amount of
time.  At X minus some reasonable Y, an email is sent to the address
in the sign-up advising them to renew.

This reduces the burden on ASF volunteers, doesn't unduly burden
distributors, and ensures users/buyers have timely information.

Though I still think this might be better in a user forum.

Don

Re: Bring back the distributors page!

2012-06-01 Thread John

1)   How important is to your business to have the "Community Distributor"
logo on your website, or to otherwise have access to OpenOffice logos and
branding?

 

I think it would benefit both the seller and the buyer knowing that they are
buying from a known distributor. So I would say that this is a good idea to
use the official logos and branding.

 

2)  How important is to your business to be listed on a distribution page of
our website, www.openoffice.org?  Is this due to traffic that is generated?
Or by the implied endorsement that comes from being listed?  Or both?

 

It is of the up most importance to be listed on your distributors page due
to the traffic generated by that specific page. Also, If you take a look at
my website,   www.123openoffice.com, you can
clearly see that I have the logo on the top left of the page as a community
distributor. Also note below that, if the latest version is not up to date
on my site when it is released, I will distribute the CD free of charge.
Which is a great incentive for some people that may see that I do not have
the latest version up. I think if something like that was implemented in the
guidelines of being a distributor it would work to everyone's benefit. 

 

3)  If we made a "distributor" logo available for use by OpenOffice
distributors, but under specific conditions, what should those conditions
be?

 

I think the conditions should be as follows: The distributor logo must
appear on the top fold of your page. Which means you should be able to see
it without scrolling down. The logo should not be altered in any way as this
may confuse people and trick people into thinking that it is a different
office product.

 

4) Another way to think of it is this: The value of that logo is diminished
it is given to those who offer poor service.  So what would distinguish a
good distributor from a bad one?

 

For me as stated above, I issue free copies of the software if someone
requests one if I do not have the latest version available. Also if you
briefly read through my FAQ's, it explains how and why I am able to sell
something that is free. I think everyone that is a distributor should have
something similar to my FAQ's.

 

 

If you need help with any web design I would be willing to assist. As I have
created many website before and I can keep the list of distributors up to
date. I know when Alex was in charge, I would send him the links that were
out of date and websites that did not have the latest version available. But
I'm not sure why he did not keep it updated. (No offense to Alex!)

 

Let me know everyone's thoughts about the above and if I could be of
service. I also do graphic design work as well, jsgraphix.com.

 

 

Thanks,

John Schmidt

 

 

 

 

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Friday, June 01, 2012 3:52 PM
To: ooo-dev@incubator.apache.org
Cc: John Schmidt
Subject: Re: Bring back the distributors page!

 

 

Hi John,

 

First, thanks for caring enough about this to write.   It is great to

have a working distributor weigh in on these questions as we discuss them.

 

As you probably saw on the website, we took down the distribution site with
the hopes of possibly bringing it back in some form in the future.  But we
wanted to give some thought to how we could do this.

 

Could I ask you a few questions, from your perspective as a distributor?  It
would help me, and others as well, understand what your needs are.

 

1)   How important is to your business to have the "Community

Distributor" logo on your website, or to otherwise have access to OpenOffice
logos and branding?

 

2)  How important is to your business to be listed on a distribution page of
our website,   www.openoffice.org?  Is this due
to traffic that is generated?  Or by the implied endorsement that comes from
being listed?  Or both?

 

3)  If we made a "distributor" logo available for use by OpenOffice
distributors, but under specific conditions, what should those conditions
be?

 

4) Another way to think of it is this: The value of that logo is diminished
it is given to those who who offer poor service.  So what would distinguish
a good distributor from a bad one?

 

Any other thoughts would be welcome as well.

 

Regards,

 

-Rob

Re: [UX] Working with old UX wiki pages

2012-06-01 Thread RGB ES

2012/6/1 Regina Henschel :
> Hi all,
>
> there exists a lot of UX relevant pages in the MediaWiki. There had been a
> lot of ideas and wishes on the ooo-us...@incubator.apache.org recently. I
> have pointed them to Bugzilla and to these UX pages. But that seems to be
> wrong.
>
> I think, that a decision is needed, how to handle this stuff in future. I
> see this problems:
>
> (1)
> Currently some (all?) pages are assigned to category 'outdated', but that is
> not very obvious.
>
> Most of this pages have the template {{user experience}} integrated. My
> suggestion is, to put a note into this template.
>
> (2)
> At OOo times there was only the MediaWiki. But now we have the MediaWiki and
> the CWiki. My suggestion is, to use the MediaWiki only for those things,
> which are not connected with core development and not connected with
> community building. With this premise, UX work should be on the CWiki. That
> Wiki is writable for all too, so it would be no constrain in participation.

+1. We can use MediaWiki for tutorials and documentation, and CWiki
for planning and development.


> (3)
> UX had a project "Better defaults". I thing it is worth to continue. "Better
> defaults" are often small changes which might be suitable for development
> beginners to explore the source and can be used as "easy hack", if they find
> an experienced developer to guide.

+1000!!!

Regards
Ricardo

Fwd: [CONF] Apache OpenOffice Community > Localization Plan

2012-06-01 Thread Martin Srebotnjak

Hello,

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

Lp, m.

Re: Audit of NL home pages

On Fri, Jun 1, 2012 at 4:15 PM, Marcus (OOo)  wrote:
> Am 06/01/2012 05:45 AM, schrieb Ariel Constenla-Haile:
>
>> Hi Rob, *
>>
>> On Thu, May 31, 2012 at 09:05:49PM -0400, Rob Weir wrote:
>>>
>>> We're planning on enabling the OOo 3.3.0 update server soon.  This
>>> will trigger the update prompts for OOo 3.3.0 users.  We would only
>>> offer updates for users who have an appropriate translation/platform
>>> available for them in AOO 3.4.
>>>
>>>
>>> We could just have the update direct the users to
>>> http://www.openoffice.org/download/index.html. our English language
>>> download page.
>>>
>>> I proposed that we try to do a little better and direct users to the
>>> NL home page for each language.  My assumption was that we had updated
>>> each NL page for which we had translations released with AOO 3.4.  But
>>> just to be sure that this was true, I reviewed each NL home page.
>>>
>>> I found out that we're not ready yet.  Five of the 15 NL home pages
>>> either point to older OOo versions or have other problems.  Details of
>>> what I found follow.
>>>
>>> To some extent, I can fix some of these issues without even
>>> understanding the language.  But the risk of error is increased.  So
>>> it would be far preferable to have some volunteers step forward to
>>> help here.
>>
>>
>>
>> The thread http://markmail.org/message/e7evabaog3em4d5t ended with no
>> objections, so I'd propose to apply lazy consensus and follow in the
>> download page the principle of common layout and content for NL sites.
>
>
> That's also my impression.
>
>
>> With Marcus work, the en-US download page can be fully translated, with
>> support to offer localized builds:
>>
>> http://www.openoffice.org/download/index.html
>> http://www.openoffice.org/es/descargar/index.html
>>
>> Marcus did a great job, and the download page looks really nice, there
>> is no need to waste resource once again in each NL site when it can be
>> simply translated in a plain text Markdown file, no need for the
>> translator to deal with HTML, JavaScript, etc.
>>
>> So I'd suggest we take Dave's offer
>> http://markmail.org/message/kbazlvdg73sebyqp to turn the page into
>> a template (I just hole that offer is still valid ;) ).
>
>
> In general +1.
>
> However, with the tough timeframe from Oliver (2012-06-05 until 2012-06-08)
> to enable the "OOo 3.3 --> AOO 3.4 ping" I'm not sure if this is doable. We
> still need some people to do the translation work for the languages.
>
> Maybe it's better to start to update the remaining webpages with only the
> most needed improvements and then to start the migration into mdtext files
> within the next weeks?
>
> Please note:
> I don't want to be recognized to be too negative. I just want to point out
> the risk. :-)
>

I had similar thoughts.  I can't read Hungarian, but I can still find
and replace "OOo 3.3." with "AOO 3.4" and update a hyperlink.

Then, as we get shiny new NL download pages, we can easily change the
XML to point to them.

-Rob

> Marcus
>
>
>
>
>> @Dave: If I understood correctly how templates work, for example
>> templates/brand.html
>>
>> 
>>
>> I could start with the Spanish translation I made, replacing the
>> localized text with variables of the type {{ header.something }} so that
>> you get an idea of what need to get localized.  Then this variables go
>> to the mdtext file with the text to be translated. Am I right?
>
>

Re: [WWW] XRay 6.0 is available

2012-06-01 Thread Hagar Delest


Note that it has not been translated in English yet.
Bernard said on the forum that it should be done this weekend.

Hagar


Le ven. 01 juin 2012 17:32:23 CEST, drew  a écrit :


On Fri, 2012-06-01 at 11:26 -0400, drew wrote:

On Fri, 2012-06-01 at 16:32 +0200, FR web forum wrote:

Hello list,

Bernard Marcelly publish the newest Xray version: 6.0


Outstanding!

http://www.openoffice.org/fr/Documentation/Basic/
(though the text says 'sxw' and it is an 'odt' file now, yes? ;-)



I updated the french NL website
That will be nice if you make the same with other NL pages


Updated this wiki page:
http://wiki.services.openoffice.org/wiki/Extensions_development_basic#X-Ray_tool

link to document on project site and latest sdk download page.



//drew

Re: Audit of NL home pages

2012-06-01 Thread Marcus (OOo)


Am 06/01/2012 05:45 AM, schrieb Ariel Constenla-Haile:

Hi Rob, *

On Thu, May 31, 2012 at 09:05:49PM -0400, Rob Weir wrote:

We're planning on enabling the OOo 3.3.0 update server soon.  This
will trigger the update prompts for OOo 3.3.0 users.  We would only
offer updates for users who have an appropriate translation/platform
available for them in AOO 3.4.


We could just have the update direct the users to
http://www.openoffice.org/download/index.html. our English language
download page.

I proposed that we try to do a little better and direct users to the
NL home page for each language.  My assumption was that we had updated
each NL page for which we had translations released with AOO 3.4.  But
just to be sure that this was true, I reviewed each NL home page.

I found out that we're not ready yet.  Five of the 15 NL home pages
either point to older OOo versions or have other problems.  Details of
what I found follow.

To some extent, I can fix some of these issues without even
understanding the language.  But the risk of error is increased.  So
it would be far preferable to have some volunteers step forward to
help here.



The thread http://markmail.org/message/e7evabaog3em4d5t ended with no
objections, so I'd propose to apply lazy consensus and follow in the
download page the principle of common layout and content for NL sites.


That's also my impression.


With Marcus work, the en-US download page can be fully translated, with
support to offer localized builds:

http://www.openoffice.org/download/index.html
http://www.openoffice.org/es/descargar/index.html

Marcus did a great job, and the download page looks really nice, there
is no need to waste resource once again in each NL site when it can be
simply translated in a plain text Markdown file, no need for the
translator to deal with HTML, JavaScript, etc.

So I'd suggest we take Dave's offer
http://markmail.org/message/kbazlvdg73sebyqp to turn the page into
a template (I just hole that offer is still valid ;) ).


In general +1.

However, with the tough timeframe from Oliver (2012-06-05 until 
2012-06-08) to enable the "OOo 3.3 --> AOO 3.4 ping" I'm not sure if 
this is doable. We still need some people to do the translation work for 
the languages.


Maybe it's better to start to update the remaining webpages with only 
the most needed improvements and then to start the migration into mdtext 
files within the next weeks?


Please note:
I don't want to be recognized to be too negative. I just want to point 
out the risk. :-)


Marcus




@Dave: If I understood correctly how templates work, for example
templates/brand.html



I could start with the Spanish translation I made, replacing the
localized text with variables of the type {{ header.something }} so that
you get an idea of what need to get localized.  Then this variables go
to the mdtext file with the text to be translated. Am I right?

Re: Bring back the distributors page!

On Fri, Jun 1, 2012 at 3:00 PM, John Schmidt  wrote:
> I thought this was a great idea and have always had my software up to date
> and delivered on time. I can't say anything for anyone else, but my site
> looks professional and I also supply the buyer with choices of support
> packages. I for one would like this to stay open. I have not received a sale
> since the switch to Apache Openoffice. So if you can please bring the
> distributors page back.
>

Hi John,

First, thanks for caring enough about this to write.   It is great to
have a working distributor weigh in on these questions as we discuss
them.

As you probably saw on the website, we took down the distribution site
with the hopes of possibly bringing it back in some form in the
future.  But we wanted to give some thought to how we could do this.

Could I ask you a few questions, from your perspective as a
distributor?  It would help me, and others as well, understand what
your needs are.

1)   How important is to your business to have the "Community
Distributor" logo on your website, or to otherwise have access to
OpenOffice logos and branding?

2)  How important is to your business to be listed on a distribution
page of our website, www.openoffice.org?  Is this due to traffic that
is generated?  Or by the implied endorsement that comes from being
listed?  Or both?

3)  If we made a "distributor" logo available for use by OpenOffice
distributors, but under specific conditions, what should those
conditions be?

4) Another way to think of it is this: The value of that logo is
diminished it is given to those who who offer poor service.  So what
would distinguish a good distributor from a bad one?

Any other thoughts would be welcome as well.

Regards,

-Rob

>
>
> Thanks so much,
>
> John
>

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

On Fri, Jun 1, 2012 at 3:10 PM, Pedro Giffuni  wrote:
>
> Ugh ...
>
> --- Ven 1/6/12, Rob Weir  ha scritto:
> ...
>
>>
>> No release is buildable on its own.  You need an
>> operating system, a compiler, often other pre-existing
>> libraries on the system, other prerequisites that need
>> to be installed by the developers.
>>
>
> And computers need electricity, which is not free and
> not available under a compatible license. I wish you
> could keep focused or at least do an effort to
> understand the issues so we can solve them.
>

Be nice.

> The tarball release must be consistent; we cannot hide
> tarballs in SVN. Creating a directory with the Category-A
> tarballs that form a base of the release along with the
> base distribution is not really a problem. Some of them
> are not available upstream anymore.
>

That is one possible technique.  But not the only one.  I'm a
committer on another Apache project, the ODF Toolkit, and we do not
include any of the dependencies in our release, not even other
category-a ones.  All of them are downloaded on the fly from a central
repository.  That is the beauty of Maven.

There are advantages of disadvantages of each approach.  But we can't
reject one approach outright with a policy argument.  Both methods are
in use at Apache today.

-rob

> Pedro.
>
>
>
>
>
>
>> Even in its cleanest form, a Java program using Maven, a
>> release will
>> not build until the user first installs Maven.
>>
>> So no one (except maybe you) is arguing that our release
>> should be
>> buildable without any dependencies that are not included in
>> the
>> release.   The real questions should be
>> thought of from the
>> developer's perspective:
>>
>> 1) What dependencies are mandatory and which ones are
>> optional, needed
>> only for specific features?
>>
>> 2) What are the obligations that a developer has when they
>> make use
>> of, or modify code in a particular dependency?
>>
>> 3) What do I need to provision my dev environment to build,
>> with or
>> without any given dependency.
>>
>> What we do at Apache, providing open source software for the
>> good, is
>> directed to making things simple for the downstream
>> consumers of our
>> releases.
>>
>> What we're doing with ext_sources is making #3 far easier,
>> for the
>> developer, compared to tracking down and fetching
>> dependencies from
>> other websites.  And I think we've taken the proper
>> steps to provide
>> information, build flags, NOTICE and LICENSE files to cover
>> the other
>> two concerns.
>>
>>
>> >
>> >
>> >>
>>  We also agreed to clean up as much as
>> possible of the dependencies to
>>  category-b stuff over time. But that takes
>> time and is a lot of work.
>> >>>
>> >>> I admit this is very clear. I don't expect such
>> development to be
>> >>> a requirement for graduation but the transitory
>> situation of a source
>> >>> release that depends on carrying category-B
>> tarballs in SVN now is
>> >>> not really acceptable.
>> >>
>> >> well that is exactly the question. I don't know for
>> sure if it is a real
>> >> problem to have them in svn.
>> >>
>> >> svn or any other server would be equal as long as
>> we don't
>> >> change/improve the download part.
>> >>
>> >> So the real problem seems to be a different one.
>> >>
>> >
>> > I will address the Category-B + patches issue on
>> another email.
>> >
>> >
>>

Re: Bring back the distributors page!

2012-06-01 Thread Donald Whytock

On Fri, Jun 1, 2012 at 3:00 PM, John Schmidt  wrote:
> I thought this was a great idea and have always had my software up to date
> and delivered on time. I can't say anything for anyone else, but my site
> looks professional and I also supply the buyer with choices of support
> packages. I for one would like this to stay open. I have not received a sale
> since the switch to Apache Openoffice. So if you can please bring the
> distributors page back.

Perhaps a user forum thread for service suppliers would be better than
a webpage.  A webpage has to be maintained and can have links that are
out of date, whereas a forum thread is more dynamic and would seem
more up-to-date.

Don

Bring back the distributors page!

2012-06-01 Thread John Schmidt

I thought this was a great idea and have always had my software up to date
and delivered on time. I can't say anything for anyone else, but my site
looks professional and I also supply the buyer with choices of support
packages. I for one would like this to stay open. I have not received a sale
since the switch to Apache Openoffice. So if you can please bring the
distributors page back.

 

Thanks so much,

John

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)


Ugh ...

--- Ven 1/6/12, Rob Weir  ha scritto:
...

> 
> No release is buildable on its own.  You need an
> operating system, a compiler, often other pre-existing
> libraries on the system, other prerequisites that need
> to be installed by the developers.
>

And computers need electricity, which is not free and
not available under a compatible license. I wish you
could keep focused or at least do an effort to
understand the issues so we can solve them.

The tarball release must be consistent; we cannot hide
tarballs in SVN. Creating a directory with the Category-A
tarballs that form a base of the release along with the
base distribution is not really a problem. Some of them
are not available upstream anymore.

Pedro.





 
> Even in its cleanest form, a Java program using Maven, a
> release will
> not build until the user first installs Maven.
> 
> So no one (except maybe you) is arguing that our release
> should be
> buildable without any dependencies that are not included in
> the
> release.   The real questions should be
> thought of from the
> developer's perspective:
> 
> 1) What dependencies are mandatory and which ones are
> optional, needed
> only for specific features?
> 
> 2) What are the obligations that a developer has when they
> make use
> of, or modify code in a particular dependency?
> 
> 3) What do I need to provision my dev environment to build,
> with or
> without any given dependency.
> 
> What we do at Apache, providing open source software for the
> good, is
> directed to making things simple for the downstream
> consumers of our
> releases.
> 
> What we're doing with ext_sources is making #3 far easier,
> for the
> developer, compared to tracking down and fetching
> dependencies from
> other websites.  And I think we've taken the proper
> steps to provide
> information, build flags, NOTICE and LICENSE files to cover
> the other
> two concerns.
> 
> 
> >
> >
> >>
>  We also agreed to clean up as much as
> possible of the dependencies to
>  category-b stuff over time. But that takes
> time and is a lot of work.
> >>>
> >>> I admit this is very clear. I don't expect such
> development to be
> >>> a requirement for graduation but the transitory
> situation of a source
> >>> release that depends on carrying category-B
> tarballs in SVN now is
> >>> not really acceptable.
> >>
> >> well that is exactly the question. I don't know for
> sure if it is a real
> >> problem to have them in svn.
> >>
> >> svn or any other server would be equal as long as
> we don't
> >> change/improve the download part.
> >>
> >> So the real problem seems to be a different one.
> >>
> >
> > I will address the Category-B + patches issue on
> another email.
> >
> >
>

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

On Fri, Jun 1, 2012 at 12:37 PM, Pedro Giffuni  wrote:
> Hi Jürgen;
>
>
> On 06/01/12 03:16, Jürgen Schmidt wrote:
>>
>> On 5/31/12 6:26 PM, Pedro Giffuni wrote:
>>>
>>> ...
>>>
>>> First of all we should clarify what a source release is in this context.
>>> Does our source release contain Category-A tarballs? In other
>>> words, does this file:
>>>
>>> http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2
>>>
>> I hoped that was clear, our source release files don't contain any
>> tar-balls from ext_sources
>
> OK. So what we are releasing is only the part of the SVN tree labelled
> "main",
> (not sure if ext_libraries is included, it should be). I would think a
> source
> release should be able to build without having to look for extra libraries
> in
> our SVN. Call me old fashioned but I am thinking of people trying to
> distribute the sources in a CD-ROM.
>
>
>
>>> Build on it's own? Or are developers/builders expected to download
>>> more tarballs from SVN.
>>
>> yes, you unpack the source, solve some basic build env requirements
>> according the building guide, run configure and build. The tar-balls get
>> downloaded during the bootstrap step automatically.
>>
>> After checking it again, the only drawback currently is that all
>> tar-balls are downloaded even if they are not used. That is true for all
>> categories.
>>
>> But this is something that we can improve for the 3.5 (already started).
>> We should only download the tar-balls that we need by configure ...
>>
>> Why not 3.4.1? Because it is a maintenance release only and we want to
>> be careful. For 3.4.1 we change the url to download from our 3.4 revision.
>
> I think all releases must respect Apache policies ASAP.
>
>
>>
 It seems to be really an item for legal to decide if hosting the
 category-b tar-balls in svn is not allowed for convenience at all.

 Furthermore we agreed to accept and of course support the move to
 another server but it is important that we don't break our 3.4 release.
>>>
>>> As you noted before, removing Category-B tarballs shouldn't break
>>> the default build. But I will go further ahead with mentioning that
>>> the 3.4 Release is theoretically broken already with the Lucene and
>>> Apache Commons updates (the development branch is for
>>> development, right?), and since no one complained people must be
>>> getting the files from somewhere else.
>>
>> well that is a very bad example and probably wrong. We all know or
>> expect that not many people will build AOO from the source release.
>> People who are interested will more likely check it out from svn as you
>> and I did it as well.
>
> I think the problem is your definition of source release. The source release
> in the source tarballs should be 1:1 equivalent to the source release in
> SVN.
> If you think release (in the tarball) is only what you have under "main"
> then
> we do have trouble moving dependencies in the tree. but if you include the
> tarballs in the release, then we don't have trouble. In other words:
>
> If 3.4.1-Release is this:
> http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/
> it has never been broken.
> If it is only this:
> http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/main/
>
> Then the release is unbuildable on it's own.
>

No release is buildable on its own.  You need an operating system, a
compiler, often other pre-existing libraries on the system, other
prerequisites that need to be installed by the developers.

Even in its cleanest form, a Java program using Maven, a release will
not build until the user first installs Maven.

So no one (except maybe you) is arguing that our release should be
buildable without any dependencies that are not included in the
release.   The real questions should be thought of from the
developer's perspective:

1) What dependencies are mandatory and which ones are optional, needed
only for specific features?

2) What are the obligations that a developer has when they make use
of, or modify code in a particular dependency?

3) What do I need to provision my dev environment to build, with or
without any given dependency.

What we do at Apache, providing open source software for the good, is
directed to making things simple for the downstream consumers of our
releases.

What we're doing with ext_sources is making #3 far easier, for the
developer, compared to tracking down and fetching dependencies from
other websites.  And I think we've taken the proper steps to provide
information, build flags, NOTICE and LICENSE files to cover the other
two concerns.


>
>
>>
 We also agreed to clean up as much as possible of the dependencies to
 category-b stuff over time. But that takes time and is a lot of work.
>>>
>>> I admit this is very clear. I don't expect such development to be
>>> a requirement for graduation but the transitory situation of a source
>>> release that depends on carrying category-B tarballs in SVN now

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)


Hi Jürguen;

On 06/01/12 05:09, Jürgen Schmidt wrote:

Hi,

sorry for top posting but I followed Ross advice and will give a
concrete example.

Hunspell ->  MPL + LGPL

Hunspell illustrates a case that I would consider unsupported but
valid for redistribution.

My opinion on the MPL+ patches is as follows.


-I don't see a problem patching the MPL sources for two reasons:
1) We don't do this by default, the patches are only there for
convenience to external packagers. It must be made clear they
are unsupported though.
2) The patches are under ALv2.

I do think it would be consistent with (1) to disable category-B in the
buildbots: The category-B dependencies as they are right now
(built from source and patched) are unsupported. We can officially
support them only if we use binaries (I am thinking of Java bytecode
and fonts).

I would like now to point out another case that points out a
real issue:

We are using Seamonkey version 1.1.14 and we are patching it.
Version 1.1.14 is unsupported upstream and the Mozilla Foundation
doesn't carry it anymore. For all purposes it seems like we have forked
this package and can be considered "upstream".

We are not allowed to distribute MPL code at all, and even if we just
mirror it for convenience to our users, like in this case, we will always
be exposed to becoming the mainstream distributors of forked code.

Pedro.





- we use currently version 1.2.9 and compile the source in our build env
on demand when the correct configure switch is used

- we apply 4 or in case of mingw 5 patch files (depends on the mechanism
that is used in our build env generally for this kind of things)

3 of these patch files contains minor changes used/necessary for our
build env.

For example hunspell-solaris.patch:
###
--- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx 2010-02-27
23:42:05.0 +
+++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx2010-02-27
23:43:02.0 +
@@ -10,6 +10,9 @@
  #include "hunspell.hxx"
  #include "csutil.hxx"

+// switch off iconv support for tests (fixing Solaris problems)
+#undef HAVE_ICONV
+
  #ifndef HUNSPELL_EXTRA
  #define suggest_auto suggest
  #endif
###

One patch apply a back port patch for an important issue that is fixed
in a newer version. Don't ask me why we haven't upgraded the version
already. But that is as I mentioned before on our plan.

hunspell-stackmash.patch
###
--- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx   2010-03-04
10:25:06.0 +
+++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
10:25:38.0 +
@@ -1665,7 +1665,7 @@
if (!q2) return 0; // bad XML input
if (check_xml_par(q, "type=", "analyze")) {
int n = 0, s = 0;
-  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
analyze(slst, cw);
+  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
analyze(slst, cw);
if (n == 0) return 0;
// convert the result toana1ana2  format
for (int i = 0; i<  n; i++) s+= strlen((*slst)[i]);
@@ -1686,13 +1686,13 @@
(*slst)[0] = r;
return 1;
} else if (check_xml_par(q, "type=", "stem")) {
-  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
stem(slst, cw);
+  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
stem(slst, cw);
} else if (check_xml_par(q, "type=", "generate")) {
-  int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
+  int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
if (n == 0) return 0;
char * q3 = strstr(q2 + 1, "'), MAXWORDUTF8LEN)) {
+if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
  return generate(slst, cw, cw2);
  }
} else {
###

This fix is fixed upstream in version 1.2.11, see
http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell/hunspell.cxx?r1=1.8&r2=1.9


That means with our further ongoing improvements in this area we get rid
of this patch and have only minor patches for our build env.

Building these libs on demand in our build env is for convenience.
Otherwise we would have to put them somewhere else, have to duplicate
the build env or would need to build them with our build env and use the
binary libraries from there. That would mean a further huge burden to
make the development for AOO more complicate.

I hope this helps

Juergen


On 6/1/12 11:07 AM, Ross Gardler wrote:

On 1 June 2012 09:50, Jürgen Schmidt  wrote:

On 6/1/12 9:47 AM, Ross Gardler wrote:

Sent from my mobile device, please forgive errors and brevity.
On May 31, 2012 5:26 PM, "Pedro Giffuni"  wrote:

...


I admit this is very clear. I don't expect such development to be
a requirement for graduation but the transitory situation of a source
release that depends on carrying category-B tarballs in SVN now is
not really acceptable.

I do expect this to be sorted out before graduation.

it is addressed already


That might be as simple as getting clarity on

Re: how Get Bitmap file from SVG module?

2012-06-01 Thread Armin Le Grand


Hi jianlizhao,

On 01.06.2012 06:22, jianlizhao wrote:

Hi Armin:
You say this I understanding.
I would  insert original image aoo's write and display, I do not how to do it 
with zip file？


I am not sure I understand what you need to know. The method described 
is just a possibility to check the file content of ODF files.


If you insert the reduced Bitmap as GraphicObject in a ODF document and 
save it, it will be contained.


I understood from your last comments that including the raw data 
directly to ODF is not needed. Instead it is set as kind of comment to 
the inserted GraphicObject and thus evtl. indirectly saved and included 
in the ODF. How this may happen I have no idea, sorry.


HTH!


Look forward to your reply.
  Best Regards!


-邮件原件-
发件人: Armin Le Grand [mailto:armin.le.gr...@me.com]
发送时间: 2012年5月31日 22:28
收件人: ooo-dev@incubator.apache.org
主题: Re: how Get Bitmap file from SVG module?

Hi jianlizhao,

much more simple, only a trick to look at the contents of a ODF file.

Example: Save the file (e.g. foo.odf), extend filename (e.g. in explorer
on windows) by *.ziz (->  foo.odf.zip). You can the open the odf file as
zip archive and inspect/check it's contents.

HTH!


[..]

Sincerely,
Armin
--
ALG

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

Hi Jürgen;

On 06/01/12 03:16, Jürgen Schmidt wrote:

On 5/31/12 6:26 PM, Pedro Giffuni wrote:

...
First of all we should clarify what a source release is in this context.
Does our source release contain Category-A tarballs? In other
words, does this file:
http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2

I hoped that was clear, our source release files don't contain any
tar-balls from ext_sources
OK. So what we are releasing is only the part of the SVN tree labelled
"main",
(not sure if ext_libraries is included, it should be). I would think a
source
release should be able to build without having to look for extra
libraries in

our SVN. Call me old fashioned but I am thinking of people trying to
distribute the sources in a CD-ROM.

Build on it's own? Or are developers/builders expected to download
more tarballs from SVN.

yes, you unpack the source, solve some basic build env requirements
according the building guide, run configure and build. The tar-balls get
downloaded during the bootstrap step automatically.

After checking it again, the only drawback currently is that all
tar-balls are downloaded even if they are not used. That is true for all
categories.

But this is something that we can improve for the 3.5 (already started).
We should only download the tar-balls that we need by configure ...

Why not 3.4.1? Because it is a maintenance release only and we want to
be careful. For 3.4.1 we change the url to download from our 3.4 revision.

I think all releases must respect Apache policies ASAP.

It seems to be really an item for legal to decide if hosting the
category-b tar-balls in svn is not allowed for convenience at all.

Furthermore we agreed to accept and of course support the move to
another server but it is important that we don't break our 3.4 release.

As you noted before, removing Category-B tarballs shouldn't break
the default build. But I will go further ahead with mentioning that
the 3.4 Release is theoretically broken already with the Lucene and
Apache Commons updates (the development branch is for
development, right?), and since no one complained people must be
getting the files from somewhere else.

well that is a very bad example and probably wrong. We all know or
expect that not many people will build AOO from the source release.
People who are interested will more likely check it out from svn as you
and I did it as well.

I think the problem is your definition of source release. The source release
in the source tarballs should be 1:1 equivalent to the source release in
SVN.
If you think release (in the tarball) is only what you have under "main"
then

we do have trouble moving dependencies in the tree. but if you include the
tarballs in the release, then we don't have trouble. In other words:

If 3.4.1-Release is this:
http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/
it has never been broken.
If it is only this:
http://svn.apache.org/viewvc/incubator/ooo/branches/AOO34/main/

Then the release is unbuildable on it's own.

We also agreed to clean up as much as possible of the dependencies to
category-b stuff over time. But that takes time and is a lot of work.

I admit this is very clear. I don't expect such development to be
a requirement for graduation but the transitory situation of a source
release that depends on carrying category-B tarballs in SVN now is
not really acceptable.

well that is exactly the question. I don't know for sure if it is a real
problem to have them in svn.

svn or any other server would be equal as long as we don't
change/improve the download part.

So the real problem seems to be a different one.

I will address the Category-B + patches issue on another email.

Re: OS/2 Java VM not working

2012-06-01 Thread Yuri Dario

Hi Jurgen,

> you can try to instantiate the Java loader via Basic
> 
> Sub Main
> o = createUnoService("com.sun.star.loader.Java2")
> msgbox o.dbg_supportedinterfaces
> End Sub


do you know which modules are required to get  VM working?

TIA!

-- 
Bye,

Yuri Dario

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

Re: [UX] Working with old UX wiki pages

2012-06-01 Thread Paulo de Souza Lima

2012/6/1 Regina Henschel 

> Hi all,
>
>
Hi


> there exists a lot of UX relevant pages in the MediaWiki. There had been a
> lot of ideas and wishes on the ooo-us...@incubator.apache.org recently. I
> have pointed them to Bugzilla and to these UX pages. But that seems to be
> wrong.
>
> I think, that a decision is needed, how to handle this stuff in future. I
> see this problems:
>
> (1)
> Currently some (all?) pages are assigned to category 'outdated', but that
> is not very obvious.
>
> Most of this pages have the template {{user experience}} integrated. My
> suggestion is, to put a note into this template.
>

I've created that category in order to identify pages that need revision,
not only UX related pages. As soon as they are revised that category must
be removed from the pages. There are many new pages in the wiki.
Categorizing old unrevised pages in Category:Outdated makes it easier to
search for such pages and to have a good idea on how many they are and what
are their contents.


>
> (2)
> At OOo times there was only the MediaWiki. But now we have the MediaWiki
> and the CWiki. My suggestion is, to use the MediaWiki only for those
> things, which are not connected with core development and not connected
> with community building. With this premise, UX work should be on the CWiki.
> That Wiki is writable for all too, so it would be no constrain in
> participation.
>

I don't have an closed opinion about this issue. I am more familiar with
Mediawiki, but I can learn how to use Cwiki too. No problem from my side.


>
> (3)
> UX had a project "Better defaults". I thing it is worth to continue.
> "Better defaults" are often small changes which might be suitable for
> development beginners to explore the source and can be used as "easy hack",
> if they find an experienced developer to guide.
>

Sure!


>
> Kind regards
> Regina
>
>
>
Regards.

-- 
Paulo de Souza Lima
http://almalivre.wordpress.com
Curitiba - PR
Linux User #432358
Ubuntu User #28729

Re: [PROPOSAL] Starting the graduation process

2012-06-01 Thread Kay Schenk




On 05/31/2012 03:27 PM, Phillip Rhodes wrote:

On Mon, May 28, 2012 at 1:10 PM, Rob Weir  wrote:

I'd like to start the graduation process, with the aim of being a TLP
in time for the 3.4.1 release.



If, by and large, folks thing we're ready to graduate, then yes, let's
get the process started.  I personally wouldn't emphasize tying
graduation to a specific release though.  If there has to be another
"-incubating" release, I wouldn't consider that the end of the world.


Phil


+1 from me on starting the graduation process and Phil's assessment above.




--

MzK

"So let it rock, let it roll
Let the bible belt come and save my soul
Hold on to sixteen as long as you can
Changes come around real soon make us woman and men."
  -- "Jack and Diane", John Mellencamp

Re: Friendly Web www.OOoNinja.com

On Fri, 2012-06-01 at 09:37 +0800, bjcheny wrote:
> Thanks, that will be fine.
> I thought I found another place to post stuff besides wiki.
> :-) Thanks again for your sharing.

Hi,

Well, I did hear back from Andrew and though his life is rather busy
right now that wouldn't preclude you from talking with him directly
about generating new content for the site, if that is something you
seriously want to do. 

The thing to do would be to contact him directly. Would you like his
email address? 

//drew



> 
> 2012/5/31 drew 
> 
> > On Thu, 2012-05-31 at 09:20 -0400, drew wrote:
> > > On Thu, 2012-05-31 at 20:53 +0800, bjcheny wrote:
> > > > Hi,
> > > >
> > > > When I go through some links from Office OpenXML, I find this:
> > > > http://www.oooninja.com/
> > > > It's aimed to bring news/tips/howtos for openoffice.org. And it was
> > ever
> > > > maintained by  Andrew Ziem <
> > az...@openoffice.org?subject=www.OOoNinja.com> (
> > > > az...@openoffice.org).
> > > > I guess it's close with our community, and is there any story? Maybe
> > we can
> > > > take it back, and post our news/articles there.
> > >
> > > It was not, maintained by, Andrew it is Andrew's personal blog, there is
> > > nothing to take back. There is a story why it has gone silent, not
> > > appropriate for, or related to, here.
> > >
> > > Andrew also worked with Fridrich on http://libwps.sourceforge.net/ BTW.
> >
> > Hi again,
> >
> >
> > As a project (OO.o) there was some precedent for handing off private
> > resources from one member to another - such happened twice that I can
> > think of.
> >
> > I have a recent email address for Andrew and will contact him - will let
> > the list know what if anything comes of that.
> >
> >
> > //drew
> >
> > >
> > > >
> > > > There is also a similar one, GullFOSS
> > > > article<
> > http://blogs.sun.com/GullFOSS/entry/new_chart_features_in_openoffice>,
> > > > which is already gone.
> > >
> > > Yes that was an internal SUN Microsystems blog.
> > >
> > > > I wonder if there are more similar friendly webs ever which are getting
> > > > unknown to us, and we may need to take care of them, or do something.
> > > > Just a suggestion. :-)
> > > >
> > > > Regards,
> > > > Chen Ying
> > >
> > >
> > >
> >
> >
> >

Re: Friendly Web www.OOoNinja.com

On Fri, 2012-06-01 at 11:06 -0400, Louis Suárez-Potts wrote:
> On 2012-05-31, at 10:09 , drew wrote:
> 
> > On Thu, 2012-05-31 at 09:20 -0400, drew wrote:
> >> On Thu, 2012-05-31 at 20:53 +0800, bjcheny wrote:
> >>> Hi,
> >>> 
> >>> When I go through some links from Office OpenXML, I find this:
> >>> http://www.oooninja.com/
> >>> It's aimed to bring news/tips/howtos for openoffice.org. And it was ever
> >>> maintained by  Andrew Ziem 
> >>>  (
> >>> az...@openoffice.org).
> >>> I guess it's close with our community, and is there any story? Maybe we 
> >>> can
> >>> take it back, and post our news/articles there.
> >> 
> >> It was not, maintained by, Andrew it is Andrew's personal blog, there is
> >> nothing to take back. There is a story why it has gone silent, not
> >> appropriate for, or related to, here.
> >> 
> >> Andrew also worked with Fridrich on http://libwps.sourceforge.net/ BTW.
> > 
> > Hi again,
> > 
> > 
> > As a project (OO.o) there was some precedent for handing off private
> > resources from one member to another - such happened twice that I can
> > think of.
> 
> At least. Actually, "precedent' is a glorification of series of mistakes and 
> oopses, but in the end, the conclusion, which I think antedated the formation 
> of the Community Council, I and a few others came to was*:
> 
> || private sites voluntarily donated and maintained unless publicly backed by 
> policy and institution representatives (i.e., the OOo community council, at 
> the time; now, the PMC), are always more vulnerable than those arranged for 
> by contract, simply because the latter works to secure the future and 
> eliminate the uncertainty of the market, at least in theory, if not always in 
> practice, of course.
> 
> || any donated site (whatever that means), must comply with the policy (or 
> come up with a better one that the governing body can adopt), and part of 
> that policy really ought to have provisions for hand-over. 
> 
> *  [We—mostly Sun/Hamburg--never implemented these points in full b/c of 
> corporate resistance and never really scripted them; they existed more as 
> conversations, and that's a pity. The consequences of that failure of policy 
> writing can be seen here and there. ]
> 
> My take is that little is lost by having policy guidelines and if those 
> guidelines need amendment or outright expunging, fine: do it. No policy ought 
> to be thought of as cut into stone—that's what makes it a policy and not a 
> law or even commandment.
> 
> Of course, any policy pertaining to something like the Ninja site or any 
> other promotional site personally maintained ought to be, logically, 
> consistent with any mirrors site or any other public site representing OOo, 
> yes?

Hi Louis,

IMO - the individual supporter sites were and are a very real asset.

The examples I mentioned where example of an open community working.
Someone did something good, they wanted to discontinue and came to the
mailing list, at the project and asked if there was anyone interested in
continuing. There was and they do. In both cases if you, as an
individual, think they could have newer and or better content then help
make some - they both take contributions from anyone interested.

In some other cases sites may have come and gone but even contracting
(whatever that really means beyond a rather informal nod) do the same
also.

Sure I completely agree that a supporter site must track the projects
desires with regards to branding, in these cases they were certainly
recognized as acceptable by the community.

There is also nothing stopping others from offering sites with
overlapping services - the user base is sizable and certainly benefits,
IMO, from a more networked info/support environment, with providers of
all sorts.

Where the project can improve is in how it presents to users what is
available in that universe. 

//drew

Re: [Request] Korean language pack and id for pootle server

On 6/1/12 5:39 PM, Jihui Choi wrote:
> Hi, Jürgen.
> Thank you so much for quick and kind respond.
> 
> I understand apache's rule and why that is important. And I don't want
> to bother you.
> I guess there's few people who can speak korean, so it will be very
> hard to check
> korean contribution.
> 
> I was in OOo Korean team for serveral years and I led the team for 2 years.
> So I know how it rolls. I think I can handle OOo source and po, pootle, etc,.

I believe that and I see no problem here long term, it is more how it
works here at Apache and we have to take the initial steps ;-)

> 
> Though I'm not quite sure about iCLA, I'm interested in. I'm gonna
> read iCLA statement
> carefully and I wanna follow the process.
> 
> 
> Jürgen, can I send you a mail personally after I send iCLA to apache
> foundation for further process?

sure if you want but on the mailing is also ok. The advantage on the
mailing list is that potentially others can benefit from the information
as well. But chose the approach whatever is more more suitable for you.

Juergen

Re: [Request] Korean language pack and id for pootle server

Hi, Jürgen.
Thank you so much for quick and kind respond.

I understand apache's rule and why that is important. And I don't want
to bother you.
I guess there's few people who can speak korean, so it will be very
hard to check
korean contribution.

I was in OOo Korean team for serveral years and I led the team for 2 years.
So I know how it rolls. I think I can handle OOo source and po, pootle, etc,.

Though I'm not quite sure about iCLA, I'm interested in. I'm gonna
read iCLA statement
carefully and I wanna follow the process.


Jürgen, can I send you a mail personally after I send iCLA to apache
foundation for further process?

-- 
Regards,
JiHui Choi

Re: [WWW] XRay 6.0 is available

On Fri, 2012-06-01 at 11:26 -0400, drew wrote:
> On Fri, 2012-06-01 at 16:32 +0200, FR web forum wrote:
> > Hello list,
> > 
> > Bernard Marcelly publish the newest Xray version: 6.0
> 
> Outstanding!
> 
> http://www.openoffice.org/fr/Documentation/Basic/
> (though the text says 'sxw' and it is an 'odt' file now, yes? ;-)
> 
> 
> > I updated the french NL website
> > That will be nice if you make the same with other NL pages

Updated this wiki page:
http://wiki.services.openoffice.org/wiki/Extensions_development_basic#X-Ray_tool

link to document on project site and latest sdk download page.

> 
> //drew
> 
> 
> 
>

Re: [WWW] XRay 6.0 is available

On Fri, 2012-06-01 at 16:32 +0200, FR web forum wrote:
> Hello list,
> 
> Bernard Marcelly publish the newest Xray version: 6.0

Outstanding!

http://www.openoffice.org/fr/Documentation/Basic/
(though the text says 'sxw' and it is an 'odt' file now, yes? ;-)

> I updated the french NL website
> That will be nice if you make the same with other NL pages

//drew

Re: [Request] Korean language pack and id for pootle server

Hi JiHui Choi,

first of all thanks for joining the mailing list and offering your help.

On 6/1/12 5:05 PM, Jihui Choi wrote:
> Hello, all.
> My name is Jihui Choi.
> 
> I'd like to give some help for Korean l10n. I was a member of Korean
> translation team of OOo and I translated OOo getting started.
> 
> Recently OOo 3.4 was released, but there's no korean language pack.
> I was told because no one asked it and no one can maintain korean translation.
> If it's ok, I can maintain korean translation.
> 
> And I couldn't find any link for registeration of pootle server.
> https://translate.apache.org
> 
> How can I get login id?

On the pootle server it is only possible to get a login as committer. We
know that this a limitation you have 2 other options.

If you are able to work offline directly on the po files, I can send you
the files via email. And when you have finished the work you can send
the files back to me.

Or you can make suggestion as unknown on pootle and inform me when you
have finished the work. A committer have to review your changes and can
accept them.

I know it is not very convenient but the only possibility we have right now.

But I am trying to work with volunteers to establish them as soon as
possible in the project.

When you are interested to get deeper involved in the project over time
you might think about sending the iCLA back to Apache. More information
about the iCLA and the reason why it is important for us here at Apache
can find here http://www.apache.org/licenses/#clas

iCLA can be found here http://www.apache.org/licenses/icla.txt

Please let me know which way you prefer and I will send you the po files
asap.

I am working also on preparing some basic information how new
translators can start...

Thanks again

Juergen

[RELEASE][3.4.1]: propose issues 119676 + 119677 for AOO3.4.1

Hi,

119676
the index page of the 3.4 SDK contains some broken links that I would
like to correct. It's trivial fix and will affect the SDK only.

119678
autodoc generates a wrong copyright footer in the generated html
reference documentation

Both issues are not really critical but the first improve the usability
and will link to the correct license. And the second one will generate a
correct footer for the reference documentation that will be used on our
webpage as well.

Juergen

Re: Friendly Web www.OOoNinja.com

2012-06-01 Thread Louis Suárez-Potts

On 2012-05-31, at 10:09 , drew wrote:

> On Thu, 2012-05-31 at 09:20 -0400, drew wrote:
>> On Thu, 2012-05-31 at 20:53 +0800, bjcheny wrote:
>>> Hi,
>>> 
>>> When I go through some links from Office OpenXML, I find this:
>>> http://www.oooninja.com/
>>> It's aimed to bring news/tips/howtos for openoffice.org. And it was ever
>>> maintained by  Andrew Ziem  (
>>> az...@openoffice.org).
>>> I guess it's close with our community, and is there any story? Maybe we can
>>> take it back, and post our news/articles there.
>> 
>> It was not, maintained by, Andrew it is Andrew's personal blog, there is
>> nothing to take back. There is a story why it has gone silent, not
>> appropriate for, or related to, here.
>> 
>> Andrew also worked with Fridrich on http://libwps.sourceforge.net/ BTW.
> 
> Hi again,
> 
> 
> As a project (OO.o) there was some precedent for handing off private
> resources from one member to another - such happened twice that I can
> think of.

At least. Actually, "precedent' is a glorification of series of mistakes and 
oopses, but in the end, the conclusion, which I think antedated the formation 
of the Community Council, I and a few others came to was*:

|| private sites voluntarily donated and maintained unless publicly backed by 
policy and institution representatives (i.e., the OOo community council, at the 
time; now, the PMC), are always more vulnerable than those arranged for by 
contract, simply because the latter works to secure the future and eliminate 
the uncertainty of the market, at least in theory, if not always in practice, 
of course.

|| any donated site (whatever that means), must comply with the policy (or come 
up with a better one that the governing body can adopt), and part of that 
policy really ought to have provisions for hand-over. 

*  [We—mostly Sun/Hamburg--never implemented these points in full b/c of 
corporate resistance and never really scripted them; they existed more as 
conversations, and that's a pity. The consequences of that failure of policy 
writing can be seen here and there. ]

My take is that little is lost by having policy guidelines and if those 
guidelines need amendment or outright expunging, fine: do it. No policy ought 
to be thought of as cut into stone—that's what makes it a policy and not a law 
or even commandment.

Of course, any policy pertaining to something like the Ninja site or any other 
promotional site personally maintained ought to be, logically, consistent with 
any mirrors site or any other public site representing OOo, yes?

> 
> I have a recent email address for Andrew and will contact him - will let
> the list know what if anything comes of that.

Thanks
Louis
> 
> 
> //drew
> 
>> 
>>> 
>>> There is also a similar one, GullFOSS
>>> article,
>>> which is already gone.
>> 
>> Yes that was an internal SUN Microsystems blog.
>> 
>>> I wonder if there are more similar friendly webs ever which are getting
>>> unknown to us, and we may need to take care of them, or do something.
>>> Just a suggestion. :-)
>>> 
>>> Regards,
>>> Chen Ying
>> 
>> 
>> 
> 
>

[Request] Korean language pack and id for pootle server

Hello, all.
My name is Jihui Choi.

I'd like to give some help for Korean l10n. I was a member of Korean
translation team of OOo and I translated OOo getting started.

Recently OOo 3.4 was released, but there's no korean language pack.
I was told because no one asked it and no one can maintain korean translation.
If it's ok, I can maintain korean translation.

And I couldn't find any link for registeration of pootle server.
https://translate.apache.org

How can I get login id?

Thanks, all.

-- 
Regards,
JiHui Choi

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

2012-06-01 Thread Andre Fischer




On 01.06.2012 14:03, Rob Weir wrote:

On Fri, Jun 1, 2012 at 3:17 AM, Andre Fischer  wrote:

On 31.05.2012 18:12, Rob Weir wrote:


On Thu, May 31, 2012 at 11:19 AM, Andre Fischerwrote:


On 31.05.2012 14:51, Rob Weir wrote:



On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni  wrote:





--- Mer 30/5/12, Rob Weir  ha scritto:




[...]



So instead of a an axe, let's try a scalpel.  The ext_sources tree was
branched along with the rest of the the AOO 3.4 tree.  So you should
be able to safely work on the branch, defining the external
dependencies there.  This could be done without touching the trunk and
without breaking the 3.4.0 release.  Then, after 3.4.1 is released, we
can bring those changes to the trunk.

Does that make sense?  We don't break our release distributions until
we have a working replacement in the form of 3.4.1.  If that means we
delay graduation until 3.4.1, then so be it.




You are talking about a new branch, right, not the 3.4.1 branch?



I thought the 3.4.1 branch would be appropriate.  Move the category-b
tarballs to Apache Extras, and make the build fetch from there instead
of from SVN.  That way the trunk's copy of these dependencies doesn't
disappear yet.  Then when we release 3.4.1, we have a release that is
not dependent on the SVN copies, and we can safely remove them then.



My understanding is that we have to make sure that the files referenced by
the (source) release do not go away.  That did not work so well for the 3.4
release because they where referenced on trunk.  If the 3.4.1 release
references the files on the branch then that should be safe(r).
Trunk is where the main part of development takes place.



In an ideal world, yes.  We would never break the AOO 3.4.0 release
source package.  But one compromise could be to first relocate the
cat-b tarballs for 3.4.1 release.  And once that release is made, then
do the changes that would break the 3.4.0 source package.

If we do this then we ensure that the latest source distribution can
always build.


Maybe you are right.  May resistance against such changes in 3.4.1 comes 
from the rules we had at Sun/Oracle: only fix severe bugs and not 
introduce new regressions.


Anyway, I am working on the changes to fetch_tarballs.sh:

- The conversion to a Perl script is already done (it is already notably 
faster on Windows when no packages have to be downloaded)


- I can specify multiple download sites for each file.  The majority of 
tar balls can be downloaded from their original servers.


- Fallback download server will be Apache Extras.

I hope that the work will be finished by Monday.

-Andre







The problem we have now is that even though we branched after the 3.4
release, the build script is still fetching from the trunk copy of the
dependencies.  So we need to fix this is a somewhat backwards way.



For the 3.4 release we have to restore the tar-balls that where deleted
since the release.  That does of course not mean that the newer versions
have to be removed as well.  Due to different version numbers and MD5 sums
they have different names and can coexist.

-Andre




Or am I missing something?

-Rob


-Andre

[WWW] XRay 6.0 is available

2012-06-01 Thread FR web forum

Hello list,

Bernard Marcelly publish the newest Xray version: 6.0
I updated the french NL website
That will be nice if you make the same with other NL pages

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service

Hi,

On 01.06.2012 15:09, Rob Weir wrote:

On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann
wrote:

[snip]

(3) Fill the landing page [6] with content and links and activate tracking
for
this page.
-- at least one volunteer is needed here.

Instead of a new landing page it looks like that we will go for the
corresponding NL pages.
I will update the links in the XML document accordingly.
Rob: Can you provide the URL parameters for the Google Analytics tracking?
I will use "?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade" when
I am updating the XML document. Please refine, if needed - Thx in advance.

That is correct for upgrades from the 3.3 client. But we would
change the "utm_source" parameter when we enable OOo 3.2. updates.

Also, if we follow Andrea's proposal, we don't link to the NL home
page, but to the NL's download page directly. (If I understand
correctly).

For example, Spanish upgrade URL would be:

http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade

I have check some of the NL pages. Some are linking to localized download sites,
some to the English one.

For our first phase we only need the Italian one. This is already available [1].

I will fill the XML document check.Update.full with the localized download
pages. The languages which have no localized ones I will keep the NL home page.
We have then time until next Thursday to update these pages and the
corresponding links.

[1] http://www.openoffice.org/it/download/

Best regards, Oliver.

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service

2012-06-01 Thread Roberto Galoppini

On Fri, Jun 1, 2012 at 3:42 PM, Oliver-Rainer Wittmann
 wrote:
> Hi,
>
>
> On 01.06.2012 15:09, Rob Weir wrote:
>>
>> On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann
>>   wrote:
>>>
>>> Hi,
>>>
>>> next and refined steps - see below.
>>>
>>> Please hold me back, if the schedule is too tough.
>>>
>>> Best regards, Oliver.
>>>
>>> On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote:

 [snip]

 Ok.
 Roberto, Rob and Kay are in favor to activate the update service only
 for
 a part
 of the possible OOo 3.3 instances in order to check, if the traffic can
 be
 handled. No objections from my side.

 One important remark which I had not given yet:
 When we had the redirect from [5] to [4] established by the ASF
 infrastructure
 team, all (yes, all) installed OOo 3.3 instances in which the check of
 updates
 is initiated will get the XML document. Whose which find an entry with
 their
 data (language, platform, architecture) will state that an update is
 available.
 All the others will state that the OOo 3.3 installation is up to date.

 To start this first phase the following tasks need to be finished:
 (1) Choose the OOo 3.3 candidates for the first phase.
 -- orw's proposal: italian on all four platforms
>>>
>>>
>>>
>>> It looks like we will go for it.
>>> Thus, I will reduce the current XML document to the italian entries.
>>>
>>>
 (2) Get in contact with the ASF infrastructure team to get the redirect
 established at a certain day.
 -- orw is volunteering for this task
>>>
>>>
>>>
>>> I will try to get in contact with ASF infrastructure team today.
>>>
>>>
 (3) Fill the landing page [6] with content and links and activate
 tracking
 for
 this page.
 -- at least one volunteer is needed here.
>>>
>>>
>>>
>>> Instead of a new landing page it looks like that we will go for the
>>> corresponding NL pages.
>>> I will update the links in the XML document accordingly.
>>> Rob: Can you provide the URL parameters for the Google Analytics
>>> tracking?
>>> I will use "?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade"
>>> when
>>> I am updating the XML document. Please refine, if needed - Thx in
>>> advance.
>>>
>>
>> That is correct for upgrades from the 3.3 client.   But we would
>> change the "utm_source" parameter when we enable OOo 3.2. updates.
>>
>
> Ok and yes, the parameter can be changed for the update service of other
> versions.
>
>
>> Also, if we follow Andrea's proposal, we don't link to the NL home
>> page, but to the NL's download page directly.   (If I understand
>> correctly).
>>
>
> Ok, I will update it.
>
> Recently, I have removed the already reduced XML document, because the ASF
> infrastructure wants to establish the redirect before 2012-06-05.
> Thus, our first phase will start, when I (or somebody else) recreate it.
>
>
>> For example, Spanish upgrade URL would be:
>>
>>
>> http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade
>>
>
> I will check for the Italian download page for our first phase next week.

Cool, so it seems we are in good shape to start this early next week.
Let me know when we need start monitoring the auto-update traffic for
the Italian releases.

Thanks,

Roberto

>
> Best regards, Oliver.

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

[UX] Working with old UX wiki pages

2012-06-01 Thread Regina Henschel


Hi all,

there exists a lot of UX relevant pages in the MediaWiki. There had been 
a lot of ideas and wishes on the ooo-us...@incubator.apache.org 
recently. I have pointed them to Bugzilla and to these UX pages. But 
that seems to be wrong.


I think, that a decision is needed, how to handle this stuff in future. 
I see this problems:


(1)
Currently some (all?) pages are assigned to category 'outdated', but 
that is not very obvious.


Most of this pages have the template {{user experience}} integrated. My 
suggestion is, to put a note into this template.


(2)
At OOo times there was only the MediaWiki. But now we have the MediaWiki 
and the CWiki. My suggestion is, to use the MediaWiki only for those 
things, which are not connected with core development and not connected 
with community building. With this premise, UX work should be on the 
CWiki. That Wiki is writable for all too, so it would be no constrain in 
participation.


(3)
UX had a project "Better defaults". I thing it is worth to continue. 
"Better defaults" are often small changes which might be suitable for 
development beginners to explore the source and can be used as "easy 
hack", if they find an experienced developer to guide.


Kind regards
Regina

Re: OS/2 Java VM not working

On 6/1/12 3:39 PM, Yuri Dario wrote:
> Hi,
> 
> I'm working to get java supported also in the OS/2 build. I have 
> already adapted jvmfwk and other parts to recognize OS/2 JVM. Now AOO 
> can detect the JVM and even start an instance (according to logs).
> 
> But I cannot get wizards to show or db tables editor; AOO simply 
> ignores the menu selections (I see some disk activity related to vm 
> start but nothing more).
> 
> Is there around some test code to check the VM?
> 
> thanks!
> 

you can try to instantiate the Java loader via Basic

Sub Main
o = createUnoService("com.sun.star.loader.Java2")
msgbox o.dbg_supportedinterfaces
End Sub

Juergen

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service

Hi,

On 01.06.2012 15:09, Rob Weir wrote:

On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann
wrote:

Hi,

next and refined steps - see below.

Please hold me back, if the schedule is too tough.

Best regards, Oliver.

On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote:

[snip]

Ok.
Roberto, Rob and Kay are in favor to activate the update service only for
a part
of the possible OOo 3.3 instances in order to check, if the traffic can be
handled. No objections from my side.

One important remark which I had not given yet:
When we had the redirect from [5] to [4] established by the ASF
infrastructure
team, all (yes, all) installed OOo 3.3 instances in which the check of
updates
is initiated will get the XML document. Whose which find an entry with
their
data (language, platform, architecture) will state that an update is
available.
All the others will state that the OOo 3.3 installation is up to date.

To start this first phase the following tasks need to be finished:
(1) Choose the OOo 3.3 candidates for the first phase.
-- orw's proposal: italian on all four platforms

It looks like we will go for it.
Thus, I will reduce the current XML document to the italian entries.

(2) Get in contact with the ASF infrastructure team to get the redirect
established at a certain day.
-- orw is volunteering for this task

I will try to get in contact with ASF infrastructure team today.

(3) Fill the landing page [6] with content and links and activate tracking
for
this page.
-- at least one volunteer is needed here.

That is correct for upgrades from the 3.3 client. But we would
change the "utm_source" parameter when we enable OOo 3.2. updates.

Ok and yes, the parameter can be changed for the update service of other
versions.

Also, if we follow Andrea's proposal, we don't link to the NL home
page, but to the NL's download page directly. (If I understand
correctly).

Ok, I will update it.

Recently, I have removed the already reduced XML document, because the ASF
infrastructure wants to establish the redirect before 2012-06-05.

Thus, our first phase will start, when I (or somebody else) recreate it.

For example, Spanish upgrade URL would be:

http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade

I will check for the Italian download page for our first phase next week.

Best regards, Oliver.

OS/2 Java VM not working

2012-06-01 Thread Yuri Dario

Hi,

I'm working to get java supported also in the OS/2 build. I have 
already adapted jvmfwk and other parts to recognize OS/2 JVM. Now AOO 
can detect the JVM and even start an instance (according to logs).

But I cannot get wizards to show or db tables editor; AOO simply 
ignores the menu selections (I see some disk activity related to vm 
start but nothing more).

Is there around some test code to check the VM?

thanks!

-- 
Bye,

Yuri Dario

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

Re: version 3.2.1 NL

2012-06-01 Thread Regina Henschel


Nick Koopmans schrieb:

Dear sir,



We recently started with Open Office in our lessons at our school instead of
using MS Office. We train our students to do the exams in ECDL (European
Computing Drivers Licence)

We made lessons, assignments en tests in version 3.2.1

In the new image to be made for our school computers, we need Open Office
version 3.2.1 NL (dutch)

The problem is that I cannot find this version on the Internet. Every link
goes to version 3.4 (the newest)

Can you help me to obtain version 3.2.1 NL (dutch)



Thank you very much for your help,



Try it here
http://ftp-1.gwdg.de/pub/openoffice/archive/localized/nl/3.2.1/

Kind regards
Regina

Re: Blogs back (?)

On Fri, 2012-06-01 at 13:37 +0800, Kevin Grignon wrote:
> On Friday, June 1, 2012, drew wrote:


> > >
> > >
> > > KG01 - Yes, I may need your help posting to the blog for the first time.
> > I
> > > suspect I will also need help with the social media promotion, given my
> > > geography.
> > >
> >
> > Hi Kevin,
> >
> > Geography, China, yes?
> 
> 
> KG02 - Yes, that is the problem Chin_ese Fire_wall blocks social network
> access.

Howdy Kevin,


A reminder the quill is mightier then the jian.

> 
> >
> > If so, IIRC Imacat was looking for someone to help with a Chinese
> > language FB[1] page, a good resource opportunity IMO for the project :)
> 
> 
> KG02 - I'd love to, however, I'm French-Canadian. My Mandarin skills are
> Limited, and only verbal. I do not study characters.

Well, I figured it was a long shot.

> 
> >
> > Looking forward to the first UX blog post,
> >
> > //drew
> >
> > [1] http://www.facebook.com/groups/ooo.tw/
> >
> > 
> >
> >

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service

On Fri, Jun 1, 2012 at 5:58 AM, Oliver-Rainer Wittmann
 wrote:
> Hi,
>
> next and refined steps - see below.
>
> Please hold me back, if the schedule is too tough.
>
> Best regards, Oliver.
>
> On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote:
>>
>>
>> [snip]
>>
>>
>>
>> Ok.
>> Roberto, Rob and Kay are in favor to activate the update service only for
>> a part
>> of the possible OOo 3.3 instances in order to check, if the traffic can be
>> handled. No objections from my side.
>>
>> One important remark which I had not given yet:
>> When we had the redirect from [5] to [4] established by the ASF
>> infrastructure
>> team, all (yes, all) installed OOo 3.3 instances in which the check of
>> updates
>> is initiated will get the XML document. Whose which find an entry with
>> their
>> data (language, platform, architecture) will state that an update is
>> available.
>> All the others will state that the OOo 3.3 installation is up to date.
>>
>>
>> To start this first phase the following tasks need to be finished:
>> (1) Choose the OOo 3.3 candidates for the first phase.
>> -- orw's proposal: italian on all four platforms
>
>
> It looks like we will go for it.
> Thus, I will reduce the current XML document to the italian entries.
>
>
>> (2) Get in contact with the ASF infrastructure team to get the redirect
>> established at a certain day.
>> -- orw is volunteering for this task
>
>
> I will try to get in contact with ASF infrastructure team today.
>
>
>> (3) Fill the landing page [6] with content and links and activate tracking
>> for
>> this page.
>> -- at least one volunteer is needed here.
>
>
> Instead of a new landing page it looks like that we will go for the
> corresponding NL pages.
> I will update the links in the XML document accordingly.
> Rob: Can you provide the URL parameters for the Google Analytics tracking?
> I will use "?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade" when
> I am updating the XML document. Please refine, if needed - Thx in advance.
>

That is correct for upgrades from the 3.3 client.   But we would
change the "utm_source" parameter when we enable OOo 3.2. updates.

Also, if we follow Andrea's proposal, we don't link to the NL home
page, but to the NL's download page directly.   (If I understand
correctly).

For example, Spanish upgrade URL would be:

http://www.openoffice.org/es/descargar/index.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade

>
>> (4) Choose the time frame for the first phase.
>> -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be
>> established
>> on Tuesday, 2012-07-05 and task (3) can be finished until Monday.)
>>
>
> Needs to be read: 2012-06-05 until 2012-06-08
> As the italian NL page is in a good shape and no objections are raised so
> far I think we can go for it.
>
> Best regards, Oliver.

version 3.2.1 NL

2012-06-01 Thread Nick Koopmans

Dear sir,

 

We recently started with Open Office in our lessons at our school instead of
using MS Office. We train our students to do the exams in ECDL (European
Computing Drivers Licence)

We made lessons, assignments en tests in version 3.2.1

In the new image to be made for our school computers, we need Open Office
version 3.2.1 NL (dutch)

The problem is that I cannot find this version on the Internet. Every link
goes to version 3.4 (the newest)

Can you help me to obtain version 3.2.1 NL (dutch)

 

Thank you very much for your help,

 

Nick Koopmans

ICT manager Olympus College

http://www.olmpuscollege.nl

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service


Hi,

On 01.06.2012 14:29, Oliver-Rainer Wittmann wrote:


[snip]

(2) Get in contact with the ASF infrastructure team to get the redirect
established at a certain day.
-- orw is volunteering for this task


I will try to get in contact with ASF infrastructure team today.


I have submitted JIRA issue INFRA-4871, found at
https://issues.apache.org/jira/browse/INFRA-4871

I am currently trying to get in direct contact with the ASF infrastructure team 
to discuss details and to clarify, if the request (INFRA-4871) can be fulfilled.


Best regards, Oliver.

Re: Wiki, Forum Host Names (was: [wiki] login not secure...)

2012-06-01 Thread Albino B Neto

Hi.

2012/5/29 imacat :
> Dear all,
>
>    I think it might be better to start a new thread.
>
>    Anyway, the current wiki/forums hostnames are:
>
> 1. wiki.services.openoffice.org
>   user.services.openoffice.org
>
>    (The "user" host only hosts user forums, nothing more.)
>
>    There is suggestion to shorten them to:
>
> 2. wiki.openoffice.org
>   user.openoffice.org
>
>    However, I would like to revised proposal#2 to:
>
> 3. wiki,openoffice.org
>   forum.openoffice.org
>
>    Or simply,
>
> 4. w.openoffice.org
>   f.openoffice.org
>
>    Any ideas?  Or any other proposal?

+1

You can also leave:

w.oo.org > wiki.oo.org
f.oo.org > forum.oo.org

If you enter will simplified to page.

Albino

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service


Hi,

some status update - see below

On 01.06.2012 11:58, Oliver-Rainer Wittmann wrote:

Hi,

next and refined steps - see below.

Please hold me back, if the schedule is too tough.

Best regards, Oliver.

On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote:


[snip]


Ok.
Roberto, Rob and Kay are in favor to activate the update service only for a part
of the possible OOo 3.3 instances in order to check, if the traffic can be
handled. No objections from my side.

One important remark which I had not given yet:
When we had the redirect from [5] to [4] established by the ASF infrastructure
team, all (yes, all) installed OOo 3.3 instances in which the check of updates
is initiated will get the XML document. Whose which find an entry with their
data (language, platform, architecture) will state that an update is available.
All the others will state that the OOo 3.3 installation is up to date.


To start this first phase the following tasks need to be finished:
(1) Choose the OOo 3.3 candidates for the first phase.
-- orw's proposal: italian on all four platforms


It looks like we will go for it.
Thus, I will reduce the current XML document to the italian entries.


I have updated the current XML document [1]
The full version can be found at [2] or [3].




(2) Get in contact with the ASF infrastructure team to get the redirect
established at a certain day.
-- orw is volunteering for this task


I will try to get in contact with ASF infrastructure team today.


(3) Fill the landing page [6] with content and links and activate tracking for
this page.
-- at least one volunteer is needed here.


Instead of a new landing page it looks like that we will go for the
corresponding NL pages.
I will update the links in the XML document accordingly.
Rob: Can you provide the URL parameters for the Google Analytics tracking?
I will use "?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade" when I am
updating the XML document. Please refine, if needed - Thx in advance.



The XML document (and the full version) now contain links to the NL pages 
inclusive the Google Analytics tracking parameter.



(4) Choose the time frame for the first phase.
-- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established
on Tuesday, 2012-07-05 and task (3) can be finished until Monday.)



Needs to be read: 2012-06-05 until 2012-06-08
As the italian NL page is in a good shape and no objections are raised so far I
think we can go for it.



[1] 
http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update
[2] 
http://www.openoffice.org/projects/update36/ProductUpdateService/check.Update.full

[3] http://people.apache.org/~orw/testupdateservice/check.Update


Best regards, Oliver.

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

On Fri, Jun 1, 2012 at 3:17 AM, Andre Fischer  wrote:
> On 31.05.2012 18:12, Rob Weir wrote:
>>
>> On Thu, May 31, 2012 at 11:19 AM, Andre Fischer  wrote:
>>>
>>> On 31.05.2012 14:51, Rob Weir wrote:


 On Wed, May 30, 2012 at 9:45 PM, Pedro Giffuni    wrote:
>
>
>
>
> --- Mer 30/5/12, Rob Weir    ha scritto:
>>>
>>>
>>>
>>> [...]
>>>
>>>
 So instead of a an axe, let's try a scalpel.  The ext_sources tree was
 branched along with the rest of the the AOO 3.4 tree.  So you should
 be able to safely work on the branch, defining the external
 dependencies there.  This could be done without touching the trunk and
 without breaking the 3.4.0 release.  Then, after 3.4.1 is released, we
 can bring those changes to the trunk.

 Does that make sense?  We don't break our release distributions until
 we have a working replacement in the form of 3.4.1.  If that means we
 delay graduation until 3.4.1, then so be it.
>>>
>>>
>>>
>>> You are talking about a new branch, right, not the 3.4.1 branch?
>>>
>>
>> I thought the 3.4.1 branch would be appropriate.  Move the category-b
>> tarballs to Apache Extras, and make the build fetch from there instead
>> of from SVN.  That way the trunk's copy of these dependencies doesn't
>> disappear yet.  Then when we release 3.4.1, we have a release that is
>> not dependent on the SVN copies, and we can safely remove them then.
>
>
> My understanding is that we have to make sure that the files referenced by
> the (source) release do not go away.  That did not work so well for the 3.4
> release because they where referenced on trunk.  If the 3.4.1 release
> references the files on the branch then that should be safe(r).
> Trunk is where the main part of development takes place.
>

In an ideal world, yes.  We would never break the AOO 3.4.0 release
source package.  But one compromise could be to first relocate the
cat-b tarballs for 3.4.1 release.  And once that release is made, then
do the changes that would break the 3.4.0 source package.

If we do this then we ensure that the latest source distribution can
always build.

>
>>
>> The problem we have now is that even though we branched after the 3.4
>> release, the build script is still fetching from the trunk copy of the
>> dependencies.  So we need to fix this is a somewhat backwards way.
>
>
> For the 3.4 release we have to restore the tar-balls that where deleted
> since the release.  That does of course not mean that the newer versions
> have to be removed as well.  Due to different version numbers and MD5 sums
> they have different names and can coexist.
>
> -Andre
>
>
>>
>> Or am I missing something?
>>
>> -Rob
>>
>>> -Andre

Re: Audit of NL home pages

2012-06-01 Thread Ariel Constenla-Haile

On Fri, Jun 01, 2012 at 10:54:59AM +0200, Reizinger Zoltán wrote:
> I tried to solve th Hungarian landing page mess, but it is out my
> html knowledge.
> I decided to not touch it, I can only destroy it.
> The translation I will do if I get some direction.

That's why we need to switch to MarkDown, a plain text document format;
the MarkDown syntax is rather simple, and in case of translation, the
translation only has to translate, not create content/deal (== with
MarkDown syntax).

In a prefect situation, the mdtext files would be converted to PO files.

Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

pgpcjgDlTUrp0.pgp
Description: PGP signature

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

On 1 June 2012 11:09, Jürgen Schmidt  wrote:
> I hope this helps

It certainly does - thank you for taking the time to do this. I'm not
going to comment as I am not clear on ASF policy in this case.

I will leave it a few days to hear from people who wish to either:

a) point at a written ASF policy that clearly permits this

or

b) point at a written ASF policy that clearly disallows this

(I guess there might be a need for correction of any errors Juergen
might have made, but lets be sure to stay to *facts* about this
specific case rather than conjecture or situations in other cases)

If consensus around either a) or b) is not formed then we need to seek
the input of the IPMC (remember legal@ delegated to the IPMC). If the
IPMC cannot give clarity then we go to legal@.

If we repeat this process x times (once for each case that is notably
different from this one) we'll have the clarity we need to bring
consensus and thus plan for graduation.

Once again, thank you Jeurgen.

Ross



>
> Juergen
>
>
> On 6/1/12 11:07 AM, Ross Gardler wrote:
>> On 1 June 2012 09:50, Jürgen Schmidt  wrote:
>>> On 6/1/12 9:47 AM, Ross Gardler wrote:
 Sent from my mobile device, please forgive errors and brevity.
 On May 31, 2012 5:26 PM, "Pedro Giffuni"  wrote:
>
>>
>> ...
>>
> I admit this is very clear. I don't expect such development to be
> a requirement for graduation but the transitory situation of a source
> release that depends on carrying category-B tarballs in SVN now is
> not really acceptable.

 I do expect this to be sorted out before graduation.
>>>
>>> it is addressed already
>>>
 That might be as simple as getting clarity on the policy, it might be more
 than that. However, as a mentor I am uncertain about the practice adopted
 here and as such will not encourage the IPMC to vote for graduation until
 someone in the PPMC gets clarity.
>>>
>>> what do you expect?
>>
>> Someone needs to take out all the rhetoric and abstract concepts. Pick
>> any one of the cat-b cases and describe *exactly* how it is addressed
>> in that case and *exactly* how this conforms to documented ASF
>> policies.
>>
>> Once we have clarity on the first case we can ask whether any of the
>> other cases are different and then examine those.
>>
>>> Should we remove all this dependencies and make AOO more or less
>>> unusable or better uninteresting for real usage?
>>
>> I am making no comment on what the technical solution is.
>>
>> I want to see consensus. Consensus cannot be gained by shouting at one
>> another about vague examples. I want concrete examples on a case by
>> case basis until nobody is objecting or until the issues can be
>> clearly communicated to either the IPMC or legal@ so that a
>> clarification of ASF policy can be made.
>>
>>> Anyway I think we tried everything to address this and we still work on
>>> improvements step by step. If that is not enough for graduation I would
>>> feel very unsatisfied.
>>
>> It is, and always has been, a condition of graduation that the IP
>> situation in the project conforms to ASF policies. There is a question
>> about these tarballs and it must be resolved before graduation.
>>
>> Ross
>



-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

Hi,

sorry for top posting but I followed Ross advice and will give a
concrete example.

Hunspell -> MPL + LGPL

- we use currently version 1.2.9 and compile the source in our build env
on demand when the correct configure switch is used

- we apply 4 or in case of mingw 5 patch files (depends on the mechanism
that is used in our build env generally for this kind of things)

3 of these patch files contains minor changes used/necessary for our
build env.

For example hunspell-solaris.patch:
###
--- misc/hunspell-1.2.9.orig/src/tools/hunspell.cxx 2010-02-27
23:42:05.0 +
+++ misc/build/hunspell-1.2.9/src/tools/hunspell.cxx2010-02-27
23:43:02.0 +
@@ -10,6 +10,9 @@
 #include "hunspell.hxx"
 #include "csutil.hxx"

+// switch off iconv support for tests (fixing Solaris problems)
+#undef HAVE_ICONV
+
 #ifndef HUNSPELL_EXTRA
 #define suggest_auto suggest
 #endif
###

One patch apply a back port patch for an important issue that is fixed
in a newer version. Don't ask me why we haven't upgraded the version
already. But that is as I mentioned before on our plan.

hunspell-stackmash.patch
###
--- misc/hunspell-1.2.9/src/hunspell/hunspell.cxx   2010-03-04
10:25:06.0 +
+++ misc/build/hunspell-1.2.9/src/hunspell/hunspell.cxx 2010-03-04
10:25:38.0 +
@@ -1665,7 +1665,7 @@
   if (!q2) return 0; // bad XML input
   if (check_xml_par(q, "type=", "analyze")) {
   int n = 0, s = 0;
-  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) n =
analyze(slst, cw);
+  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) n =
analyze(slst, cw);
   if (n == 0) return 0;
   // convert the result to ana1ana2 format
   for (int i = 0; i < n; i++) s+= strlen((*slst)[i]);
@@ -1686,13 +1686,13 @@
   (*slst)[0] = r;
   return 1;
   } else if (check_xml_par(q, "type=", "stem")) {
-  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN)) return
stem(slst, cw);
+  if (get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1)) return
stem(slst, cw);
   } else if (check_xml_par(q, "type=", "generate")) {
-  int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN);
+  int n = get_xml_par(cw, strchr(q2, '>'), MAXWORDUTF8LEN - 1);
   if (n == 0) return 0;
   char * q3 = strstr(q2 + 1, "'), MAXWORDUTF8LEN)) {
+if (get_xml_par(cw2, strchr(q3, '>'), MAXWORDUTF8LEN - 1)) {
 return generate(slst, cw, cw2);
 }
   } else {
###

This fix is fixed upstream in version 1.2.11, see
http://hunspell.cvs.sourceforge.net/viewvc/hunspell/hunspell/src/hunspell/hunspell.cxx?r1=1.8&r2=1.9


That means with our further ongoing improvements in this area we get rid
of this patch and have only minor patches for our build env.

Building these libs on demand in our build env is for convenience.
Otherwise we would have to put them somewhere else, have to duplicate
the build env or would need to build them with our build env and use the
binary libraries from there. That would mean a further huge burden to
make the development for AOO more complicate.

I hope this helps

Juergen


On 6/1/12 11:07 AM, Ross Gardler wrote:
> On 1 June 2012 09:50, Jürgen Schmidt  wrote:
>> On 6/1/12 9:47 AM, Ross Gardler wrote:
>>> Sent from my mobile device, please forgive errors and brevity.
>>> On May 31, 2012 5:26 PM, "Pedro Giffuni"  wrote:

> 
> ...
> 
 I admit this is very clear. I don't expect such development to be
 a requirement for graduation but the transitory situation of a source
 release that depends on carrying category-B tarballs in SVN now is
 not really acceptable.
>>>
>>> I do expect this to be sorted out before graduation.
>>
>> it is addressed already
>>
>>> That might be as simple as getting clarity on the policy, it might be more
>>> than that. However, as a mentor I am uncertain about the practice adopted
>>> here and as such will not encourage the IPMC to vote for graduation until
>>> someone in the PPMC gets clarity.
>>
>> what do you expect?
> 
> Someone needs to take out all the rhetoric and abstract concepts. Pick
> any one of the cat-b cases and describe *exactly* how it is addressed
> in that case and *exactly* how this conforms to documented ASF
> policies.
> 
> Once we have clarity on the first case we can ask whether any of the
> other cases are different and then examine those.
> 
>> Should we remove all this dependencies and make AOO more or less
>> unusable or better uninteresting for real usage?
> 
> I am making no comment on what the technical solution is.
> 
> I want to see consensus. Consensus cannot be gained by shouting at one
> another about vague examples. I want concrete examples on a case by
> case basis until nobody is objecting or until the issues can be
> clearly communicated to either the IPMC or legal@ so that a
> clarification of ASF policy can be made.
> 
>> Anyway I think we tried everything to address this and we still work on
>> improvements step by step. If that is not enough fo

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service


Hi,

next and refined steps - see below.

Please hold me back, if the schedule is too tough.

Best regards, Oliver.

On 31.05.2012 10:38, Oliver-Rainer Wittmann wrote:


[snip]


Ok.
Roberto, Rob and Kay are in favor to activate the update service only for a part
of the possible OOo 3.3 instances in order to check, if the traffic can be
handled. No objections from my side.

One important remark which I had not given yet:
When we had the redirect from [5] to [4] established by the ASF infrastructure
team, all (yes, all) installed OOo 3.3 instances in which the check of updates
is initiated will get the XML document. Whose which find an entry with their
data (language, platform, architecture) will state that an update is available.
All the others will state that the OOo 3.3 installation is up to date.


To start this first phase the following tasks need to be finished:
(1) Choose the OOo 3.3 candidates for the first phase.
-- orw's proposal: italian on all four platforms


It looks like we will go for it.
Thus, I will reduce the current XML document to the italian entries.


(2) Get in contact with the ASF infrastructure team to get the redirect
established at a certain day.
-- orw is volunteering for this task


I will try to get in contact with ASF infrastructure team today.


(3) Fill the landing page [6] with content and links and activate tracking for
this page.
-- at least one volunteer is needed here.


Instead of a new landing page it looks like that we will go for the 
corresponding NL pages.

I will update the links in the XML document accordingly.
Rob: Can you provide the URL parameters for the Google Analytics tracking?
I will use "?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade" when I am 
updating the XML document. Please refine, if needed - Thx in advance.



(4) Choose the time frame for the first phase.
-- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be established
on Tuesday, 2012-07-05 and task (3) can be finished until Monday.)



Needs to be read: 2012-06-05 until 2012-06-08
As the italian NL page is in a good shape and no objections are raised so far I 
think we can go for it.


Best regards, Oliver.

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service


Hi,

On 01.06.2012 11:05, Roberto Galoppini wrote:

On Fri, Jun 1, 2012 at 10:55 AM, Oliver-Rainer Wittmann
  wrote:

Hi,


On 31.05.2012 18:46, Roberto Galoppini wrote:


On Thu, May 31, 2012 at 10:38 AM, Oliver-Rainer Wittmann



[snip]



Ok.
Roberto, Rob and Kay are in favor to activate the update service only for
a
part of the possible OOo 3.3 instances in order to check, if the traffic
can
be handled. No objections from my side.

One important remark which I had not given yet:
When we had the redirect from [5] to [4] established by the ASF
infrastructure team, all (yes, all) installed OOo 3.3 instances in which
the
check of updates is initiated will get the XML document. Whose which find
an
entry with their data (language, platform, architecture) will state that
an
update is available. All the others will state that the OOo 3.3
installation
is up to date.



Clear.


To start this first phase the following tasks need to be finished:
(1) Choose the OOo 3.3 candidates for the first phase.
-- orw's proposal: italian on all four platforms



agree


(2) Get in contact with the ASF infrastructure team to get the redirect
established at a certain day.
-- orw is volunteering for this task
(3) Fill the landing page [6] with content and links and activate
tracking
for this page.
-- at least one volunteer is needed here.



I can volunteer for this, do we have a draft text for that?



No, there is no draft.
But Rob suggested in his reply to provide links to the corresponding NL
pages. Andrea second it and I am also in favor of it. It would save us some
resources.


agree


The needed updates to the NL pages have to be done nevertheless in my
opinion.


Andrea are you going to do that or do you want me to do so?



Rob already made a corresponding investigation and started a thread here [1].
As far as I can see from this thread the italian NL pages is in a good shape.

[1] http://ooo-dev.markmail.org/thread/7ydafrdrqxpctsy3

Best regards, Oliver.

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service

Hi,

On 31.05.2012 19:56, Rob Weir wrote:

On Thu, May 31, 2012 at 4:38 AM, Oliver-Rainer Wittmann
wrote:

[snip]

Ok.
Roberto, Rob and Kay are in favor to activate the update service only for a
part of the possible OOo 3.3 instances in order to check, if the traffic can
be handled. No objections from my side.

One important remark which I had not given yet:
When we had the redirect from [5] to [4] established by the ASF
infrastructure team, all (yes, all) installed OOo 3.3 instances in which the
check of updates is initiated will get the XML document. Whose which find an
entry with their data (language, platform, architecture) will state that an
update is available. All the others will state that the OOo 3.3 installation
is up to date.

To start this first phase the following tasks need to be finished:
(1) Choose the OOo 3.3 candidates for the first phase.
-- orw's proposal: italian on all four platforms
(2) Get in contact with the ASF infrastructure team to get the redirect
established at a certain day.
-- orw is volunteering for this task
(3) Fill the landing page [6] with content and links and activate tracking
for this page.
-- at least one volunteer is needed here.
(4) Choose the time frame for the first phase.
-- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be
established on Tuesday, 2012-07-05 and task (3) can be finished until
Monday.)

BTW, as we have for each language own entries in the XML document we can
provide translated landing pages if somebody is willing to translate the
"master" landing page.

Is the text in the dialog box in OOo 3.3 localized? The text that
says an update is available, please go to this page to download? Or
is that in English only?

It is localized.

One approach might be to have the landing page be the NL home page,
e.g., http://de.openoffice.org. These already exist, and either have
the download links on that page, or have text that explains how to
download. (En is the exception -- we'd send them to
http://download.openoffice.org directly)

+1 for using the NL pages as the "update landing pages".

To distinguish these visits from non-upgrade visits, we could tag them
using URL parameters in a way that Google Analytics can understand.

For example:

http://www.openoffice.org/download.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade

http://www.openoffice.org/de/index.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade

http://www.openoffice.org/it/index.html?utm_source=OOo3_3&utm_medium=Client&utm_campaign=Upgrade

The extra parameters would be ignored by our website, but GA would
understand them.

No problem to include such parameters.

One other question: does this take care of OOo 3.2 upgrades as well?

Not yet planned nor tested, but I assume that the XML document only needs minor
adjustments.

OOo 3.2 has the UpdateURL http://update34.services.openoffice.org/...
OOo 3.2.1 has the Update URL http://update35.services.openoffice.org/...

But once the update service is working for OOo 3.3, we can easily do the same
for OOo 3.2 and OOo 3.2.1 (and even former versions). We can redirect these URLs
to another XML document which contains different "update landing page URLs" in
order to distinguish e.g. OOo 3.2 update requests from OOo 3.3 update requests.

Before activating the update service for former versions I would like to think
about including languages/platform combinations for which we do _not_ have yet
an installation package available. It could be a possibility to aware these
users about the AOO 3.4 release. May be we can get feedback which languages
and/or platforms our users are requesting. May be we can activate certain
volunteers for these languages/platforms. May be certain users would be also
satisfied with another localization.

Do we think there are many out there?

I do not know.

OOo 3.2 was released at 2010-02-11, OOo 3.2.1 at 2010-06-03.
OOo 3.3 was out at 2011-01-27. I assume that at this time the former update
services for OOo 3.2 and OOo 3.2.1 were available. Thus, the users had at least
2,5 months (until mid April 2011) to upgrade. May be former update services were
longer available - I do not know.
I could conclude that our OOo 3.2/3.2.1 user base is small compared to the OOo
3.3 one from these assumption, but I am not sure.

Best regards, Oliver.

[6]
http://www.openoffice.org/projects/update36/ProductUpdateService/index.html

Re: [BUILD] There is a build break on Mac OS X 10.5.8

2012-06-01 Thread Herbert Duerr


Hello Chao Huang,


The build break was reported in module SAL. Here is the details
--
Entering 
/Users/hchao/Apache/build/aoo.340.20120601/aoo.340.r1343441/main/sal/util

ERROR: error 10 occurred while making
/Users/hchao/Apache/build/aoo.340.20120601/aoo.340.r1343441/main/sal/util


I suggest to:

cd /Users/hchao/Apache/build/aoo.340.20120601/aoo.340.r1343441/main/sal/
build verbose=t

and then report the errors here. Please note that attachments seem to 
get stripped on this mailing list.


Herbert

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

On 1 June 2012 09:50, Jürgen Schmidt  wrote:
> On 6/1/12 9:47 AM, Ross Gardler wrote:
>> Sent from my mobile device, please forgive errors and brevity.
>> On May 31, 2012 5:26 PM, "Pedro Giffuni"  wrote:
>>>

...

>>> I admit this is very clear. I don't expect such development to be
>>> a requirement for graduation but the transitory situation of a source
>>> release that depends on carrying category-B tarballs in SVN now is
>>> not really acceptable.
>>
>> I do expect this to be sorted out before graduation.
>
> it is addressed already
>
>> That might be as simple as getting clarity on the policy, it might be more
>> than that. However, as a mentor I am uncertain about the practice adopted
>> here and as such will not encourage the IPMC to vote for graduation until
>> someone in the PPMC gets clarity.
>
> what do you expect?

Someone needs to take out all the rhetoric and abstract concepts. Pick
any one of the cat-b cases and describe *exactly* how it is addressed
in that case and *exactly* how this conforms to documented ASF
policies.

Once we have clarity on the first case we can ask whether any of the
other cases are different and then examine those.

> Should we remove all this dependencies and make AOO more or less
> unusable or better uninteresting for real usage?

I am making no comment on what the technical solution is.

I want to see consensus. Consensus cannot be gained by shouting at one
another about vague examples. I want concrete examples on a case by
case basis until nobody is objecting or until the issues can be
clearly communicated to either the IPMC or legal@ so that a
clarification of ASF policy can be made.

> Anyway I think we tried everything to address this and we still work on
> improvements step by step. If that is not enough for graduation I would
> feel very unsatisfied.

It is, and always has been, a condition of graduation that the IP
situation in the project conforms to ASF policies. There is a question
about these tarballs and it must be resolved before graduation.

Ross

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service

2012-06-01 Thread Roberto Galoppini

On Fri, Jun 1, 2012 at 10:55 AM, Oliver-Rainer Wittmann
 wrote:
> Hi,
>
>
> On 31.05.2012 18:46, Roberto Galoppini wrote:
>>
>> On Thu, May 31, 2012 at 10:38 AM, Oliver-Rainer Wittmann
>>>
>>>
>>> [snip]
>>>
>>>
>>>
>>> Ok.
>>> Roberto, Rob and Kay are in favor to activate the update service only for
>>> a
>>> part of the possible OOo 3.3 instances in order to check, if the traffic
>>> can
>>> be handled. No objections from my side.
>>>
>>> One important remark which I had not given yet:
>>> When we had the redirect from [5] to [4] established by the ASF
>>> infrastructure team, all (yes, all) installed OOo 3.3 instances in which
>>> the
>>> check of updates is initiated will get the XML document. Whose which find
>>> an
>>> entry with their data (language, platform, architecture) will state that
>>> an
>>> update is available. All the others will state that the OOo 3.3
>>> installation
>>> is up to date.
>>
>>
>> Clear.
>>
>>> To start this first phase the following tasks need to be finished:
>>> (1) Choose the OOo 3.3 candidates for the first phase.
>>> -- orw's proposal: italian on all four platforms
>>
>>
>> agree
>>
>>> (2) Get in contact with the ASF infrastructure team to get the redirect
>>> established at a certain day.
>>> -- orw is volunteering for this task
>>> (3) Fill the landing page [6] with content and links and activate
>>> tracking
>>> for this page.
>>> -- at least one volunteer is needed here.
>>
>>
>> I can volunteer for this, do we have a draft text for that?
>
>
> No, there is no draft.
> But Rob suggested in his reply to provide links to the corresponding NL
> pages. Andrea second it and I am also in favor of it. It would save us some
> resources.

agree

> The needed updates to the NL pages have to be done nevertheless in my
> opinion.

Andrea are you going to do that or do you want me to do so?

Roberto

>
>>
>>> (4) Choose the time frame for the first phase.
>>> -- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be
>>> established on Tuesday, 2012-07-05 and task (3) can be finished until
>>> Monday.)
>>
>>
>> SourceForge's side we are ok with this tentative schedule.
>>
>
> I meant 2012-06-05 until 2012-06-08, as it has been already recognized.
>
> Best regards, Oliver.
>
>>
>>>
>>>
>>> BTW, as we have for each language own entries in the XML document we can
>>> provide translated landing pages if somebody is willing to translate the
>>> "master" landing page.
>>>
>>> [6]
>>>
>>> http://www.openoffice.org/projects/update36/ProductUpdateService/index.html
>>>
>

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Re: Audit of NL home pages

2012-06-01 Thread Reizinger Zoltán


2012.06.01. 3:05 keltezéssel, Rob Weir írta:

We're planning on enabling the OOo 3.3.0 update server soon.  This
will trigger the update prompts for OOo 3.3.0 users.  We would only
offer updates for users who have an appropriate translation/platform
available for them in AOO 3.4.


We could just have the update direct the users to
http://www.openoffice.org/download/index.html. our English language
download page.

I proposed that we try to do a little better and direct users to the
NL home page for each language.  My assumption was that we had updated
each NL page for which we had translations released with AOO 3.4.  But
just to be sure that this was true, I reviewed each NL home page.

I found out that we're not ready yet.  Five of the 15 NL home pages
either point to older OOo versions or have other problems.  Details of
what I found follow.

To some extent, I can fix some of these issues without even
understanding the language.  But the risk of error is increased.  So
it would be far preferable to have some volunteers step forward to
help here.
I tried to solve th Hungarian landing page mess, but it is out my html 
knowledge.

I decided to not touch it, I can only destroy it.
The translation I will do if I get some direction.
Zoltan


Thanks!

-Rob



Arabic http://www.openoffice.org/ar/index.html

The Arabic page needs some urgent help.  The downloads are pointing to
hard coded mirrors, to 3.3.0 RC1 downloads, and the links are dead.

--

Chinese (simplified)  http://www.openoffice.org/zh-cn/

OK.

--

Chinese (traditional)  http://www.openoffice.org/zh-tw/

OK

--

Czech http://www.openoffice.org/cs/

The Czech page needs some serious help.  It immediately points the
user to some off-site webpage.  It also claims the project is
sponsored by Novell and Sun, and that the latest version is OOo 2.2.

--

Dutch http://www.openoffice.org/nl/

Could use some improvements.  It using the OpenOffice.org name and not
using the new logo.  But it does link to AOO 3.4.

--

English (US) http://www.openoffice.org/download

OK

--

French  http://www.openoffice.org/fr/

OK

--

Galician http://www.openoffice.org/gl/

Needs an update.  Still points to OOo 3.3

--

German http://www.openoffice.org/de/

OK

--

Hungarian http://www.openoffice.org/hu/

Needs to special attention.  Official downloads are in small print,
but then has more prominent links to off-site
OpenOffice.org_3.2.1_FSF.hu.exe

--

Italian http://www.openoffice.org/it/

OK

--

Japanese  http://www.openoffice.org/ja/

Needs to be updated.  Links are still to OOo 3.3.

--

Portuguese (Brazilian) http://www.openoffice.org/pt-br/

OK

--

Russian http://www.openoffice.org/ru/

OK

--

Spanish http://www.openoffice.org/es/

OK

--

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service


Hi,

On 31.05.2012 18:46, Roberto Galoppini wrote:

On Thu, May 31, 2012 at 10:38 AM, Oliver-Rainer Wittmann


[snip]


Ok.
Roberto, Rob and Kay are in favor to activate the update service only for a
part of the possible OOo 3.3 instances in order to check, if the traffic can
be handled. No objections from my side.

One important remark which I had not given yet:
When we had the redirect from [5] to [4] established by the ASF
infrastructure team, all (yes, all) installed OOo 3.3 instances in which the
check of updates is initiated will get the XML document. Whose which find an
entry with their data (language, platform, architecture) will state that an
update is available. All the others will state that the OOo 3.3 installation
is up to date.


Clear.


To start this first phase the following tasks need to be finished:
(1) Choose the OOo 3.3 candidates for the first phase.
-- orw's proposal: italian on all four platforms


agree


(2) Get in contact with the ASF infrastructure team to get the redirect
established at a certain day.
-- orw is volunteering for this task
(3) Fill the landing page [6] with content and links and activate tracking
for this page.
-- at least one volunteer is needed here.


I can volunteer for this, do we have a draft text for that?


No, there is no draft.
But Rob suggested in his reply to provide links to the corresponding NL pages. 
Andrea second it and I am also in favor of it. It would save us some resources.

The needed updates to the NL pages have to be done nevertheless in my opinion.




(4) Choose the time frame for the first phase.
-- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be
established on Tuesday, 2012-07-05 and task (3) can be finished until
Monday.)


SourceForge's side we are ok with this tentative schedule.



I meant 2012-06-05 until 2012-06-08, as it has been already recognized.

Best regards, Oliver.





BTW, as we have for each language own entries in the XML document we can
provide translated landing pages if somebody is willing to translate the
"master" landing page.

[6]
http://www.openoffice.org/projects/update36/ProductUpdateService/index.html

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

On 6/1/12 9:47 AM, Ross Gardler wrote:
> Sent from my mobile device, please forgive errors and brevity.
> On May 31, 2012 5:26 PM, "Pedro Giffuni"  wrote:
>>
>> Hi Jürgen;
>>
>> Let me clarify some issues too ...
>>
>> On 05/31/12 10:39, Jürgen Schmidt wrote:
>>>
>>> ...
>>>
> 
> ...
> 
>>
>>> 6. we agreed to upstream changes to external libs where possible and
>>> necessary. And we agreed to improve the workflow to use the tar-balls
>>> from their original source where possible over time and where we can
>>> rely on the overall availability (e.g. dependencies to Apache libs, etc.)
>>>
>> Yes. Most of them are just uninteresting upstream.
> 
> This is the part that really bothers me. There is a world of difference
> between providing unmodified cat-b sources and providing modified cat-b
> sources. The ASF only releases software under the ALv2. If any of these
> cat-b sources have modifications they cannot, IMHO, be managed by the ASF
> unless specific approval for an exception to policy is sought.
> 

with my statement above I didn't differentiate between cat-a or cat-b
etc. The general approach is
- that we try to upstream patches where possible.
- we often apply patches to make the source compilable in our build env.
The reason why this is necessary is much more complex.

> If there are no modifications the position is much less clear, but still
> needs examination.
> 
>> I admit this is very clear. I don't expect such development to be
>> a requirement for graduation but the transitory situation of a source
>> release that depends on carrying category-B tarballs in SVN now is
>> not really acceptable.
> 
> I do expect this to be sorted out before graduation.

it is addressed already

> 
> That might be as simple as getting clarity on the policy, it might be more
> than that. However, as a mentor I am uncertain about the practice adopted
> here and as such will not encourage the IPMC to vote for graduation until
> someone in the PPMC gets clarity.

what do you expect?

Should we remove all this dependencies and make AOO more or less
unusable or better uninteresting for real usage?

Mmm, maybe a good idea. We would get rid of the binary releases because
nobody would be interested in them. But who would build and provide
binaries? Do you think we could attract any new developer to work on AOO
in this case?

Anyway I think we tried everything to address this and we still work on
improvements step by step. If that is not enough for graduation I would
feel very unsatisfied. We can't perform magic and we think more
practical according the Apache rules/policies as we understand them.


Juergen


> 
> As a mentor I'm not going to do it. I've been asked to stop doing stuff for
> the community and let it manage its own afairs, and I'm happy to do so.
> 
> Ross
>

Re: [HEADS UP] Re: [UPDATE SERVICE] proposal a OOo 3.3 update service


Hi,

On 31.05.2012 23:59, Andrea Pescetti wrote:

Oliver-Rainer Wittmann wrote:

(4) Choose the time frame for the first phase.
-- orw's proposal: 2012-07-05 until 2012-07-08 (if redirect can be
established on Tuesday, 2012-07-05 and task (3) can be finished until
Monday.)


You actually mean June, right? I mean, tests will start as soon as next week. Or
do you actually mean July? I see no reasons for such a long wait.



Yes, I mean June - sorry for the typo.

Please read my proposal: 2012-06-05 until 2012-06-08

Best regards, Oliver.

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)

On 5/31/12 6:26 PM, Pedro Giffuni wrote:
> Hi Jürgen;
> 
> Let me clarify some issues too ...
> 
> On 05/31/12 10:39, Jürgen Schmidt wrote:
>> ...
>> let me explain some details here because I think they can help to
>> understand.
>>
>> 1. we have dependencies to several external libraries including
>> category-b for some features
>> 2. we have checked in all this source tar-balls in ext_sources for
>> convenience and to ensure that they are always available. Another option
>> would have been to host them somewhere else on extras or any other
>> reliable server. We use the easier way for convenience reasons I think.
>> 3. our source release don't contain any category-b source tar-balls
> First of all we should clarify what a source release is in this context.
> Does our source release contain Category-A tarballs? In other
> words, does this file:
> http://www.apache.org/dyn/aoo-closer.cgi/incubator/ooo/3.4.0/source/aoo-3.4.0-incubating-src.tar.bz2
> 

I hoped that was clear, our source release files don't contain any
tar-balls from ext_sources

> 
> Build on it's own? Or are developers/builders expected to download
> more tarballs from SVN.

yes, you unpack the source, solve some basic build env requirements
according the building guide, run configure and build. The tar-balls get
downloaded during the bootstrap step automatically.

After checking it again, the only drawback currently is that all
tar-balls are downloaded even if they are not used. That is true for all
categories.

But this is something that we can improve for the 3.5 (already started).
We should only download the tar-balls that we need by configure ...

Why not 3.4.1? Because it is a maintenance release only and we want to
be careful. For 3.4.1 we change the url to download from our 3.4 revision.

> 
>> 4. from a source release perspective we don't make use of any category-b
>> stuff per default. A user have to explicitly trigger the use of
>> category-b stuff and related features. The tar-balls are downloaded on
>> demand, some kind of dependency mechanism if you want.
> So if we remove the Category-B tarballs from SVN the default
> build doesn't break, this is important. Now.. if the tarballs are
> downloaded on demand, are you meaning those are downloaded from
> SVN? (It's an honest question: I normally checkout all the tree from
> SVN, including the Category-B, tarballs so I haven't experienced the
> on-demand part of it)

exactly the tar-balls are downloaded via the svn url (see the ooo.lst
file) on demand if they are not already present. When you checkout trunk
you get them and the download is not necessary. Well that is what I
meant with convenience.

> 
> 
>> 5. the download on demand is the same and I don't really see a
>> difference between downloading the tar-balls from svn or any other place.
> OK. Do note that doing a SVN checkout, as suggested in CWiki,
> there's no easy way to exclude the category-B tarballs:
> 
> svn  co  https://svn.apache.org/repos/asf/incubator/ooo/trunk  ooo

that is true, but they are not used without further action or to
explicitly enable them.

I never said that it can't be improved and having the tar-balls in trunk
is of course not the best solution. As we have seen right now with the
latest updates that will or can break our source release when someone
use the correct configure switches.

And of course we agreed to move them and adapt the download scripts.

The whole mechanism is a little bit comparable from my pint view with
maven and how maven solve external dependencies.

> 
> 
>> 6. we agreed to upstream changes to external libs where possible and
>> necessary. And we agreed to improve the workflow to use the tar-balls
>> from their original source where possible over time and where we can
>> rely on the overall availability (e.g. dependencies to Apache libs, etc.)
>>
> Yes. Most of them are just uninteresting upstream.
> 
>> It seems to be really an item for legal to decide if hosting the
>> category-b tar-balls in svn is not allowed for convenience at all.
>>
>> Furthermore we agreed to accept and of course support the move to
>> another server but it is important that we don't break our 3.4 release.
> As you noted before, removing Category-B tarballs shouldn't break
> the default build. But I will go further ahead with mentioning that
> the 3.4 Release is theoretically broken already with the Lucene and
> Apache Commons updates (the development branch is for
> development, right?), and since no one complained people must be
> getting the files from somewhere else.

well that is a very bad example and probably wrong. We all know or
expect that not many people will build AOO from the source release.
People who are interested will more likely check it out from svn as you
and I did it as well.

> 
>> We also agreed to clean up as much as possible of the dependencies to
>> category-b stuff over time. But that takes time and is a lot of work.
> 
> I admit this is very clear. I don't expect such de

Re: [BUILD] There is a build break on Mac OS X 10.5.8

2012-06-01 Thread Chao Huang

resent the attachment. Thanks for your reminder!

2012/6/1 Peng Chen 

> Can't see the attachement.
>
> 2012/6/1 Chao Huang 
>
> > hi, all
> >
> > I checked out the source code from SVN server
> > (https://svn.apache.org/repos/asf/incubator/ooo/trunk) and the
> > revision is 1343441.
> >
> > It's OK for me to make a full build on Mac OS X 10.6.8. But there is a
> > build break on Mac OS X 10.5.8. Please note that I used the same code
> > package and configure switchers.
> >
> > The build break was reported in module SAL. Here is the details
> >
> >
> --
> > Entering
> > /Users/hchao/Apache/build/aoo.340.20120601/aoo.340.r1343441/main/sal/util
> >
> > ERROR: error 10 occurred while making
> > /Users/hchao/Apache/build/aoo.340.20120601/aoo.340.r1343441/main/sal/util
> >
> >
> ---
> >
> > My dev env is :
> > -
> > 1) Mac OS X 10.5.8
> > 2) Xcode 3.0
> > 3) gcc 4.0.1
> > 4) jdk 1.5
> > -
> >
> > I used the following configure swithcers.
> >
> >
> 
> > ./configure --with-dmake-url="
> > http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2";
> > --with-epm-url="http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz";
> > --disable-mozilla --disable-build-mozilla --enable-verbose
> > --enable-category-b --enable-minimizer --enable-presenter-console
> > --enable-wiki-publisher --disable-odk
> >
> >
> 
> >
> > At the beginning of this year, I passed the full build on both 10.5
> > and 10.6 with R1189933. So I compared file main/sal/util/makefile.mk.
> > There is only one changed line for OS2 except license. The build break
> > can be solved by recovering makefile.mk from R1343441 to R1189933.
> >
> > What I do in the next step is to copy makefile.mk (R1343441) from
> > MacOSX to WindowsXP, then convert the file format from DOS to Unix by
> > UltraEdit, copy the new file makefile.mk back to MacOSX. It's OK to
> > rebuild module SAL with the new makefile.mk.
> >
> > So I guess that there is something wrong for file
> > main/sal/util/makefile.mk. Maybe the file is broken in some extent.
> > The size of original file is 5.76K, while the re-saved one is 5.53K.
> > Please refer to the attachement.
> >
> > Is there anyone who can help to confirm this issue? Thanks!
> >
> >
> > Best regards,
> > Chao Huang
> >
>



-- 
Best regards,
Chao Huang

Re: [BUILD] There is a build break on Mac OS X 10.5.8

2012-06-01 Thread Peng Chen

Can't see the attachement.

2012/6/1 Chao Huang 

> hi, all
>
> I checked out the source code from SVN server
> (https://svn.apache.org/repos/asf/incubator/ooo/trunk) and the
> revision is 1343441.
>
> It's OK for me to make a full build on Mac OS X 10.6.8. But there is a
> build break on Mac OS X 10.5.8. Please note that I used the same code
> package and configure switchers.
>
> The build break was reported in module SAL. Here is the details
>
> --
> Entering
> /Users/hchao/Apache/build/aoo.340.20120601/aoo.340.r1343441/main/sal/util
>
> ERROR: error 10 occurred while making
> /Users/hchao/Apache/build/aoo.340.20120601/aoo.340.r1343441/main/sal/util
>
> ---
>
> My dev env is :
> -
> 1) Mac OS X 10.5.8
> 2) Xcode 3.0
> 3) gcc 4.0.1
> 4) jdk 1.5
> -
>
> I used the following configure swithcers.
>
> 
> ./configure --with-dmake-url="
> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2";
> --with-epm-url="http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz";
> --disable-mozilla --disable-build-mozilla --enable-verbose
> --enable-category-b --enable-minimizer --enable-presenter-console
> --enable-wiki-publisher --disable-odk
>
> 
>
> At the beginning of this year, I passed the full build on both 10.5
> and 10.6 with R1189933. So I compared file main/sal/util/makefile.mk.
> There is only one changed line for OS2 except license. The build break
> can be solved by recovering makefile.mk from R1343441 to R1189933.
>
> What I do in the next step is to copy makefile.mk (R1343441) from
> MacOSX to WindowsXP, then convert the file format from DOS to Unix by
> UltraEdit, copy the new file makefile.mk back to MacOSX. It's OK to
> rebuild module SAL with the new makefile.mk.
>
> So I guess that there is something wrong for file
> main/sal/util/makefile.mk. Maybe the file is broken in some extent.
> The size of original file is 5.76K, while the re-saved one is 5.53K.
> Please refer to the attachement.
>
> Is there anyone who can help to confirm this issue? Thanks!
>
>
> Best regards,
> Chao Huang
>

Re: Moving Category-B tarballs (was Re: [PROPOSAL] Starting the graduation process)