Re: svn commit: r1172617 - /incubator/ooo/trunk/main/solenv/bin/build.pl

[Pedro Giffuni]

You guys have just reminded me of codespell, a pretty nice tool
to find english mistakes and typos in code comments:

http://git.profusion.mobi/cgit.cgi/lucas/codespell/

Cheers,

Pedro.

On Mon, 19 Sep 2011 19:22:43 -0400, TJ Frazier  
wrote:

On 9/19/2011 09:33, h...@apache.org wrote:

Author: hdu
Date: Mon Sep 19 13:33:24 2011
New Revision: 1172617

URL: http://svn.apache.org/viewvc?rev=1172617&view=rev
Log:
prolongue is not in my dictionary

Modified:
 incubator/ooo/trunk/main/solenv/bin/build.pl

Modified: incubator/ooo/trunk/main/solenv/bin/build.pl
URL: 
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/bin/build.pl?rev=1172617&r1=1172616&r2=1172617&view=diff


==
--- incubator/ooo/trunk/main/solenv/bin/build.pl (original)
+++ incubator/ooo/trunk/main/solenv/bin/build.pl Mon Sep 19 13:33:24 
2011

@@ -1694,7 +1694,10 @@ sub cancel_build {
  foreach (keys %broken_build) {
  print STDERR "ERROR: error " . $broken_build{$_} . " 
occurred while making $_\n";

  };
-print STDERR "\nAttention: if you fix the errors in above 
module(s) you may prolongue your the build issuing command:\n\n\t" . 
$message_part;
+#print STDERR "\nAttention: when you fixed the errors in 
these module(s) you can resume the build by issuing the 
command:\n\n\t" . $message_part;

+print STDERR "\nWhen you fixed the errors in " .
+		(length(@broken_module_names)==1 ? "that module" : "these 
modules") .

+   " you can resume the build by running:\n\n\t" . $message_part;
  } else {
  while (children_number()) {
  handle_dead_children(1);





Thank you very much for fixing that ugly error. For the best English,
after "When you" in both places, you should either s/fixed/fix/ or
s/fixed/have fixed/ to get the tense right.

Re: Financial spreadsheet templates in .ods format

[Rob Weir]

On Mon, Sep 19, 2011 at 7:00 PM,   wrote:
> I have put together a collection of OO Calc spreadsheet files with
> templates for common financial analysis worksheets. I basically found the
> worksheets at public sites on the web in Excel format and have saved them
> to ods format and reviewed to make sure the calculations still function
> properly.  I think having templates like these accessible at the main OO
> site could help encourage migration to Calc from other spreadsheet
> products.
>
> Is a template "repository", so to speak, being considered; and what would
> be needed as far as license/attribution?
>

I'd recommend checking with the original author of the spreadsheets
(the Excel format version) and see what conditions they have on
redistribution/attribution, etc.

> Cheers,
>
>
> Scott Peterson
> Wasatch Economic Research
> Portland, OR
>

Re: AOOo can't save passwort protected file

[Pedro Giffuni]

On Mon, 19 Sep 2011 16:42:22 -0500, Pedro Giffuni 
 wrote:

On Mon, 19 Sep 2011 23:34:22 +0200, Mathias Bauer
 wrote:
...
 Just a thought ... Perhaps we should try to make Apache OO 
*really*
 Apache. I am now seeing so many nice things that other Apache 
projects
 offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just 
something

 to consider (after 3.4).


Whatever external components are added: it should be avoided to use 
Java
components for code that is loaded on startup or for loading 
"normal"

documents. If possible, Java should be used only for optional
components/features.

Except for pdfbox, all the Apache conponents I mentioned are 
available

in C/C++ versions.


(I was on my way out so I left this sort of half answered)

The issue here is xmlsec as we have it now depends on nss and openssl.
Apache Santuario has xml-security-c which only depends on openssl (and 
Xerces-c3).


The Apache way would be to use Santuario, but that is probably more 
work

than finding out why we are not using xmlsec + openssl. In both cases
we should also update OpenSSL for security reasons.

Pedro.

RE: Financial spreadsheet templates in .ods format

[Dennis E. Hamilton]

Scott,

The is a template repository for OpenOffice.org already.

Not sure how contribution works.

See .

 - Dennis

-Original Message-
From: speter...@wasatchecon.com [mailto:speter...@wasatchecon.com] 
Sent: Monday, September 19, 2011 16:01
To: ooo-dev@incubator.apache.org
Subject: Financial spreadsheet templates in .ods format

I have put together a collection of OO Calc spreadsheet files with
templates for common financial analysis worksheets. I basically found the
worksheets at public sites on the web in Excel format and have saved them
to ods format and reviewed to make sure the calculations still function
properly.  I think having templates like these accessible at the main OO
site could help encourage migration to Calc from other spreadsheet
products.

Is a template "repository", so to speak, being considered; and what would
be needed as far as license/attribution?

Cheers,


Scott Peterson
Wasatch Economic Research
Portland, OR 

Re: svn commit: r1172617 - /incubator/ooo/trunk/main/solenv/bin/build.pl

[TJ Frazier]

On 9/19/2011 09:33, h...@apache.org wrote:

Author: hdu
Date: Mon Sep 19 13:33:24 2011
New Revision: 1172617

URL: http://svn.apache.org/viewvc?rev=1172617&view=rev
Log:
prolongue is not in my dictionary

Modified:
 incubator/ooo/trunk/main/solenv/bin/build.pl

Modified: incubator/ooo/trunk/main/solenv/bin/build.pl
URL: 
http://svn.apache.org/viewvc/incubator/ooo/trunk/main/solenv/bin/build.pl?rev=1172617&r1=1172616&r2=1172617&view=diff
==
--- incubator/ooo/trunk/main/solenv/bin/build.pl (original)
+++ incubator/ooo/trunk/main/solenv/bin/build.pl Mon Sep 19 13:33:24 2011
@@ -1694,7 +1694,10 @@ sub cancel_build {
  foreach (keys %broken_build) {
  print STDERR "ERROR: error " . $broken_build{$_} . " occurred while 
making $_\n";
  };
-print STDERR "\nAttention: if you fix the errors in above module(s) you may 
prolongue your the build issuing command:\n\n\t" . $message_part;
+#print STDERR "\nAttention: when you fixed the errors in these module(s) 
you can resume the build by issuing the command:\n\n\t" . $message_part;
+print STDERR "\nWhen you fixed the errors in " .
+   (length(@broken_module_names)==1 ? "that module" : "these 
modules") .
+   " you can resume the build by running:\n\n\t" . $message_part;
  } else {
  while (children_number()) {
  handle_dead_children(1);




Thank you very much for fixing that ugly error. For the best English, 
after "When you" in both places, you should either s/fixed/fix/ or 
s/fixed/have fixed/ to get the tense right.

--
/tj/

Financial spreadsheet templates in .ods format

[speterson]

I have put together a collection of OO Calc spreadsheet files with
templates for common financial analysis worksheets. I basically found the
worksheets at public sites on the web in Excel format and have saved them
to ods format and reviewed to make sure the calculations still function
properly.  I think having templates like these accessible at the main OO
site could help encourage migration to Calc from other spreadsheet
products.

Is a template "repository", so to speak, being considered; and what would
be needed as far as license/attribution?

Cheers,


Scott Peterson
Wasatch Economic Research
Portland, OR 

Re: AOOo can't save passwort protected file

[Pedro Giffuni]

On Mon, 19 Sep 2011 23:34:22 +0200, Mathias Bauer 
 wrote:



...

 Just a thought ... Perhaps we should try to make Apache OO *really*
 Apache. I am now seeing so many nice things that other Apache 
projects
 offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just 
something

 to consider (after 3.4).


Whatever external components are added: it should be avoided to use 
Java

components for code that is loaded on startup or for loading "normal"
documents. If possible, Java should be used only for optional
components/features.


Except for pdfbox, all the Apache conponents I mentioned are available
in C/C++ versions.

Cheers,

Pedro.

Re: AOOo can't save passwort protected file

[Mathias Bauer]

Am 19.09.2011 23:07, schrieb Pedro Giffuni:

>  Hi Matias;
> 
>  On Mon, 19 Sep 2011 22:06:56 +0200, Mathias Bauer 
>   wrote:
>> Am 18.09.2011 06:10, schrieb Pedro F. Giffuni:
>>
>>>  Ugh ... nevermind, we already carry xmlsec !
>>>
>>> I guess we have everything to get rid of nss but we are not using it 
>>> right? Apache Santuario is interesting though.
>>>
>>> Cheers, Pedro.
>>
>> The reason why we went for nss when we needed AES enryption was code
>> quality. openssl was considered as badly maintained.
>>
>> Disclaimer: I just repeat what the engineer charged with the 
>> evaluation
>> reported. I didn't carry out this evaluation by myself.
>>
>  Thanks for the explanation.
> 
>  That might have been a valid reason then. The latest version is dated
>  from less than 2 weeks ago, so it looks pretty well maintained now :).
> 
>  Just a thought ... Perhaps we should try to make Apache OO *really*
>  Apache. I am now seeing so many nice things that other Apache projects
>  offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just something
>  to consider (after 3.4).

Whatever external components are added: it should be avoided to use Java
components for code that is loaded on startup or for loading "normal"
documents. If possible, Java should be used only for optional
components/features.

Regards,
Mathias

Re: A systematic approach to IP review?

[Rob Weir]

On Mon, Sep 19, 2011 at 4:32 PM, Dennis E. Hamilton
 wrote:
> I agree that there is no escape from managing down to the individual file.  
> It is a question of organization now, where the entire base is involved.
>

RAT or something RAT-like.

> Later, if the svn:property is to be trusted, the problem is quite different, 
> it seems to me.  Plus the rules are understood and provenance and IP are 
> likely handled as anything needing clearance enters the code base.  What is 
> done to ensure a previously-vetted code base has not become tainted strikes 
> me as a kind of regression/smoke test.
>

Here is how I see SVN properties and RAT relating.   Any use of a
grep-like RAT-like tool will need to deal with exceptions.  We're
going to have stuff like binary files, say ODF files that are used for
testing, that don't have a "header".  Or files that are used only as a
build tool, checked in for convenience, but are not part of the
release.  Or 3rd party code that does not have a header, but we know
its original, like the ICU breakiterator data files.

How do we deal with those types of files, in the content of an
automated audit tool?  One solution is to record in a big config file
or script a list of all of these exceptions.  Essentially, an list of
files to ignore in the RAT scan.

That approach would certainly work, but would be fragile.  Moving or
renaming the files would break our script.  Not the end of the world,
since this could be designed to be "fail safe" and give us errors on
the files that moved.

But if we track this info in SVN, then we could generate the exclusion
list from SVN, so it automatically adjusts as files are moved or
renamed.  It also avoid the problem -- and this might just be my own
engineering esthetic -- of tracking metadata for files in two
different places.  It seems rather untidy to me.

>From a regression standpoint, you could treat all files as being in
one of several states:

1) Unexamined (no property set)

2) Apache 2.0 (included in the Oracle SGA or new code contributed by
committer or other person under iCLA)

3) Compatible 3rd party license

4) Incompatible 3rd party license

5) Not part of release

The goal would be to iterate until every file is in category 2, 3 or 5.

> It is in that regard that I am concerned the tools for this one-time case 
> need not be the same as for future cases.
>

There are two kinds of future cases:

1) Code contributed in small chunks by committers or patches, where we
can expect CTR to work.  There will be errors, but we can catch those
before we do subsequent releases via RAT.

2) Larger contributions made by SGA.  For example, the IBM Lotus
Symphony contribution, or other similar corporate contributions.  When
an Apache project receives a large code contribution like this they
need to do an IP clearance process on that contribution as well.   I
think that the RAT/SVN combination could work well here also.  The
goal would be to clear the IP on the new contributions before we start
copying or merging it into the core AOOo code.


> And, since I am not doing the work in the present case, I am offering this as 
> something to think about, not a position.
>
>  - Dennis
>

Re: AOOo can't save passwort protected file

[Pedro Giffuni]

Hi Matias;

On Mon, 19 Sep 2011 22:06:56 +0200, Mathias Bauer 
 wrote:

Am 18.09.2011 06:10, schrieb Pedro F. Giffuni:


 Ugh ... nevermind, we already carry xmlsec !

I guess we have everything to get rid of nss but we are not using it 
right? Apache Santuario is interesting though.


Cheers, Pedro.


The reason why we went for nss when we needed AES enryption was code
quality. openssl was considered as badly maintained.

Disclaimer: I just repeat what the engineer charged with the 
evaluation

reported. I didn't carry out this evaluation by myself.


Thanks for the explanation.

That might have been a valid reason then. The latest version is dated
from less than 2 weeks ago, so it looks pretty well maintained now :).

Just a thought ... Perhaps we should try to make Apache OO *really*
Apache. I am now seeing so many nice things that other Apache projects
offer: Santuario, APR, pdfbox, Xerces/Xalan, Maven, etc. Just something
to consider (after 3.4).

Cheers,

Pedro.

RE: A systematic approach to IP review?

[Dennis E. Hamilton]

I agree that there is no escape from managing down to the individual file.  It 
is a question of organization now, where the entire base is involved.

Later, if the svn:property is to be trusted, the problem is quite different, it 
seems to me.  Plus the rules are understood and provenance and IP are likely 
handled as anything needing clearance enters the code base.  What is done to 
ensure a previously-vetted code base has not become tainted strikes me as a 
kind of regression/smoke test.

It is in that regard that I am concerned the tools for this one-time case need 
not be the same as for future cases.

And, since I am not doing the work in the present case, I am offering this as 
something to think about, not a position.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Monday, September 19, 2011 09:55
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?

[ ... ]

The granularity we need to worry about is the file.  That is the
finest grain level of having a license header.  That is the unit of
tracking in SVN.  That is the unit that someone could have changed the
content in SVN.

Again, it is fine if someone wants to outline this at the module
level.  But that does not eliminate the requirement for us to do this
at the file level as well.

[ ... ]

RE: A systematic approach to IP review?

[Dennis E. Hamilton]

I hope that Rat can produce a list of OK and exclude not OK on the first use, 
since the list of not OK would overwhelm everything else about the current 
repository.

 - Dennis

-Original Message-
From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] 
Sent: Monday, September 19, 2011 10:27
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?

Am 09/19/2011 07:05 PM, schrieb Rob Weir:
[ ... ]

> 3) Running RAT against the source is how we ensure that the code is clean

OK, I don't know what this can do your us. Maybe it's the solution for 
the problem.

How do you know that it is not skipping anything? I guess you simply 
would trust RAT that it is doing fine, right? ;-)

BTW:
Is RAT producing a log file, so that we have a list of every file that 
was checked? This could be very helpful.

Marcus
[ ... ]

RE: A systematic approach to IP review?

[Dennis E. Hamilton]

I agree running rat is important ...

I haven't heard any suggestion that such an important tool not be used.

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Monday, September 19, 2011 10:05
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?

[ ... ]

I think the wiki is fine as a collaboration tool, to list tasks and
who is working on them.  But that is not a substitute for running
scans with the Apache Release Audit Tool (RAT) and working toward a
clean report.

Think of it this way:

1) We have a list of modules on the wiki that we need to replace.
Great.  Developers can work on that list.

2) But how do we know that the list on the wiki is complete?  How do
we know that it is not missing anything?

3) Running RAT against the source is how we ensure that the code is clean

In other words, the criteria should be that we have a clean RAT
record, not that we have a clean wiki.  The list of modules on the
wiki is not traceable to a scan of the source code.  It is not
reproducible.  It might be useful.  But it is not sufficient.

-Rob

[ ... ]

Re: AOOo can't save passwort protected file

[Mathias Bauer]

Am 18.09.2011 06:10, schrieb Pedro F. Giffuni:

>  Ugh ... nevermind, we already carry xmlsec !
> 
> I guess we have everything to get rid of nss but we are not using it right? 
> Apache Santuario is interesting though.
> 
> Cheers, Pedro.

The reason why we went for nss when we needed AES enryption was code
quality. openssl was considered as badly maintained.

Disclaimer: I just repeat what the engineer charged with the evaluation
reported. I didn't carry out this evaluation by myself.

Regards,
Mathias

Re: automake insteed configure

[Mathias Bauer]

Am 19.09.2011 20:40, schrieb Raphael Bircher:

> Hi Herbert
> 
> Am 19.09.11 13:18, schrieb Herbert Duerr:
>>> In the past, configure was only rebuild if needed by samone (releng?) in
>>> Hamburg. Now Mathias Bauer recommends to build configure.sh everytime
>>> and make automake to the default step by the buildprocess. I think this
>>> Step should be don ASAP.
>>> I think that's not a load of changes, but I have a question: "How to run
>>> automake, and where it is located" can sameone help me.
>>
>> You probably mean "autoconf", right?
> Oh yes!
>>
>> If you are on windows install the autoconf package from cygwin. If you 
>> are on Linux install it from your package repository.
> Thanks for the hint. looks like I can make a new configure.sh by running 
> the command:
> 
> automake configure.in > configure.sh

It's easier than that: just call "autoconf" in the root folder where
configure.in is. This will create a new "configure" script in that place.

Regards,
Mathias

Re: VCL TestTool

[Frank Schönheit]

Hi Raphael,

> All good Ideas, but we should not investegate blind too much time in the 
> TT. We realy need to evaluate, what's the benefit, and how much time it 
> cost. It's a difference if we find 10 Regression or 500 in one year with 
> the TT. So the first thing is to see how much time TT save for QA.

I'm absolutely with you on this.

> In general, I'm for automated testing, because this is a good method to 
> find regressions. Skilled QA people are rare, so they should not waste 
> time with manual testing to avoind regression.

The reason why I invested time into a Java TT client was exactly this
"Skilled people should not waste time with ..."-thingie. Writing,
reading, and maintaining those Basic scripts is an art of its own. In
the rare moments I needed to deal with them as developer ('cause there
was some TT-reported bug which could not be reproduced manually, but was
nonetheless considered worth fixing), I bit into my desk multiple times,
simply 'cause working with TT is as ... unpleasant as anything.

So, *if* we say that the idea of the TT has some value - and I tend to
agree to Mathias that it indeed has -, then we should evaluate its
biggest obstacles, and work on them. To me, the Basic TT IDE is one of
those most important facets to improve.

Of course, one might think about whether the current automation approach
- in terms of how it is technically done, with all the problems as false
alarms, no complete mimic of real world user behaviour, and the like -
is, well, sufficient for the 21st century. I never thought about this in
deep, but I wouldn't be surprised if people smarter than me would come
to the conclusion that implementing this from scratch might be a better
solution. I, myself, have neither the expertise nor the time to embark
on this, so I started with were my expertise lies - which was the Java
client :)

Ciao
Frank

Re: automake insteed configure

[Raphael Bircher]

Hi Herbert

Am 19.09.11 13:18, schrieb Herbert Duerr:

In the past, configure was only rebuild if needed by samone (releng?) in
Hamburg. Now Mathias Bauer recommends to build configure.sh everytime
and make automake to the default step by the buildprocess. I think this
Step should be don ASAP.
I think that's not a load of changes, but I have a question: "How to run
automake, and where it is located" can sameone help me.


You probably mean "autoconf", right?

Oh yes!


If you are on windows install the autoconf package from cygwin. If you 
are on Linux install it from your package repository.
Thanks for the hint. looks like I can make a new configure.sh by running 
the command:


automake configure.in > configure.sh

Greetings Raphael


--
My private Homepage: http://www.raphaelbircher.ch/

Re: A systematic approach to IP review?

[Rob Weir]

On Mon, Sep 19, 2011 at 1:19 PM, Marcus (OOo)  wrote:
> Am 09/19/2011 06:54 PM, schrieb Rob Weir:
>>
>> On Mon, Sep 19, 2011 at 12:35 PM, Dennis E. Hamilton
>>   wrote:
>>>
>>> Rob,
>>>
>>> I was reading the suggestion from Marcus as it being that since the code
>>> base is in a folder structure (modularized) and the wiki can map folder
>>> structures and their status nicely, it is not necessary to have a single
>>> table to manage this from, but have any tables be at some appropriate
>>> granularity toward the leaves of the hierarchy (on the wiki).
>>>
>>
>> Using the wiki for this might be useful for tracking the status of
>> modules we already know we need to replace.  Bugzilla would be another
>> way to track the status.
>
> How do you want to use Bugzilla to track thousands of files?
>

No.  But for tracking module review, Bugzilla might be better than the
wiki.  It allows us to have a conversation on each module via
comments.

>> But it is not really a sufficient solution.  Why?  Because it is not
>> tied to the code and is not reproducible.  How was the list of
>> components listed in the wiki generated?  Based on what script?  Where
>> is the script?  How do we know it is accurate and current?  How do we
>> know that integrating a CWS does not make that list become outdated?
>> How do we prove to ourselves that we did this right?  And how to we
>> record that proof as a record?  And how do we repeat this proof every
>> time we do a new release?
>
> Questions over questions but not helpful. ;-)
>
> A list of components of unknown derivation sitting on a community wiki
>> that anyone can edit is not really a suitable basis for an IP review.
>
> Then restrict the write access.
>
>> The granularity we need to worry about is the file.  That is the
>> finest grain level of having a license header.  That is the unit of
>> tracking in SVN.  That is the unit that someone could have changed the
>> content in SVN.
>>
>> Again, it is fine if someone wants to outline this at the module
>> level.  But that does not eliminate the requirement for us to do this
>> at the file level as well.
>
> IMHO you haven't understood what I wanted to tell you.
>

I understand what you are saying.  I just don't agree with you.

> Sure it makes no sense to create a list of every file in SVN to see if the
> license is good or bad. So, do it module by module. And when a module is
> marked as "done", then of course every file in the modules was checked.
> Otherwise it's not working.
>

That is not a consistent approach. Every developer applies their own
criteria.   It is not reproducible. It leaves no audit trail.  And it
doesn't help us with the next release.

If you use the Apache Release Audit Tool (RAT) then it will check all
the files automatically.

> And how to make sure that there was no change when source was
> added/moved/improved? Simply Commit Then Review (CTR). A change in the
> license header at the beginning should be remarkable, right? However, we
> also need to have trust in everybodies work.
>

We would run RAT before every release and with every significant code
contribution.

You can think of this as a form of CTR, but one that is automated,
with a consistent rule set.

Obviously, good CTR plus the work on the wiki will all help.  But we
need the RAT scans as well, to show that we're clean.

> BTW:
> What is your plan to track every file to make sure the license is OK?
>

Run RAT.  That is what it does.

> Marcus
>
>
>
>>> I can see some brittle cases, especially in the face of refactoring.  The
>>> use of the wiki might have to be an ephemeral activity that is handled this
>>> way entirely for our initial scrubbing.
>>>
>>> Ideally, additional and sustained review would be in the SVN with the
>>> artifacts so reviewed, and coalesced somehow.  The use of SVN properties is
>>> interesting, but they are rather invisible and I have a question about what
>>> happens with them when a commit happens against the particular artifact.
>>>
>>
>> Properties stick with the file, unless changed.  Think of the
>> svn:eol-style property.  It is not wiped out with a new revision of
>> the file.
>>
>>> It seems that there is some need to balance an immediate requirement and
>>> what would be sufficient for it versus what would assist us in the longer
>>> term.  It would be interesting to know what the additional-review work has
>>> become for other projects that have a substantial code base (e.g., SVN
>>> itself, httpd, ...).  I have no idea.
>>>
>>
>> The IP review needs to occur with every release.  So the work we do to
>> automate this, and make it data-drive, will repay itself with every
>> release.
>>
>> I invite you to investigate what other projects do.  When you do I
>> think you will agree.
>>
>>>  - Dennis
>>>
>>> -Original Message-
>>> From: Rob Weir [mailto:robw...@apache.org]
>>> Sent: Monday, September 19, 2011 07:47
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: A systematic approach to IP review?
>

Re: A systematic approach to IP review?

[Marcus (OOo)]

Am 09/19/2011 07:05 PM, schrieb Rob Weir:

On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo)  wrote:

Am 09/19/2011 04:47 PM, schrieb Rob Weir:


On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)
  wrote:


Am 09/19/2011 01:59 PM, schrieb Rob Weir:


2011/9/19 Jürgen Schmidt:


On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:


If you haven't looked it closely, it is probably worth a few minutes
of your time to review our incubation status page, especially the
items under "Copyright" and "Verify Distribution Rights".  It lists
the things we need to do, including:

  -- Check and make sure that the papers that transfer rights to the
ASF been received. It is only necessary to transfer rights for the
package, the core code, and any new code produced by the project.

-- Check and make sure that the files that have been donated have been
updated to reflect the new ASF copyright.

-- Check and make sure that for all code included with the
distribution that is not under the Apache license, we have the right
to combine with Apache-licensed code and redistribute.

-- Check and make sure that all source code distributed by the project
is covered by one or more of the following approved licenses: Apache,
BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
the same terms.

Some of this is already going on, but it is hard to get a sense of who
is doing what and how much progress we have made.  I wonder if we can
agree to a more systematic approach?  This will make it easier to see
the progress we're making and it will also make it easier for others
to help.

Suggestions:

1) We need to get all files needed for the build into SVN.  Right now
there are some that are copied down from the OpenOffice.org website
during the build's bootstrap process.   Until we get the files all in
one place it is hard to get a comprehensive view of our dependencies.



do you mean to check in the files under ext_source into svn and remove
it
later on when we have cleaned up the code. Or do you mean to put it
somehwere on apache extras?
I would prefer to save these binary files under apache extra if
possible.




Why not just keep in in SVN?   Moving things to Apache-Extras does not
help us with the IP review.   In other words, if we have a dependency
on a OSS module that has an incompatible license, then moving that
module to Apache Extras does not make that dependency go away.  We
still need to understand the nature of the dependency: a build tool, a
dynamic runtime dependency, a statically linked library, an optional
extensions, a necessary core module.

If we find out, for example, that something in ext-sources is only
used as a build tool, and is not part of the release, then there is
nothing that prevents us from hosting it in SVN.   But if something is
a necessary library and it is under GPL, then this is a problem even
if we store it on Apache-Extras,






2) Continue the CWS integrations.  Along with 1) this ensures that all
the code we need for the release is in SVN.

3)  Files that Oracle include in their SGA need to have the Apache
license header inserted and the Sun/Oracle copyright migrated to the
NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
automate parts of this.

4) Once the SGA files have the Apache headers, then we can make
regular use of RAT to report on files that are lacking an Apache
header.  Such files might be in one of the following categories:

a) Files that Oracle owns the copyright on and which should be
included in an amended SGA

b) Files that have a compatible OSS license which we are permitted to
use.  This might require that we add a mention of it to the NOTICE
file.

c) Files that have an incompatible OSS license.  These need to be
removed/replaced.

d) Files that have an OSS license that has not yet been
reviewed/categorized by Apache legal affairs.  In that case we need to
bring it to their attention.

e) (Hypothetically) files that are not under an OSS license at all.
E.g., a Microsoft header file.  These must be removed.

5) We should to track the resolution of each file, and do this
publicly.  The audit trail is important.  Some ways we could do this
might be:

a) Track this in SVN properties.  So set ip:sga for the SGA files,
ip:mit for files that are MIT licensed, etc.  This should be reflected
in headers as well, but this is not always possible.  For example, we
might have binary files where we cannot add headers, or cases where
the OSS files do not have headers, but where we can prove their
provenance via other means.

b) Track this is a spreadsheet, one row per file.

c) Track this is an text log file checked in SVN

d) Track this in an annotated script that runs RAT, where the
annotations document the reason for cases where we tell it to ignore a
file or directory.

6) Iterate until we have a clean RAT report.

7) Goal should be for anyone today to be able to see what work remains
for IP clearance, as well as for someone 5 years from now to be able
to tell wh

Re: A systematic approach to IP review?

[Marcus (OOo)]

Am 09/19/2011 06:54 PM, schrieb Rob Weir:

On Mon, Sep 19, 2011 at 12:35 PM, Dennis E. Hamilton
  wrote:

Rob,

I was reading the suggestion from Marcus as it being that since the code base 
is in a folder structure (modularized) and the wiki can map folder structures 
and their status nicely, it is not necessary to have a single table to manage 
this from, but have any tables be at some appropriate granularity toward the 
leaves of the hierarchy (on the wiki).



Using the wiki for this might be useful for tracking the status of
modules we already know we need to replace.  Bugzilla would be another
way to track the status.


How do you want to use Bugzilla to track thousands of files?


But it is not really a sufficient solution.  Why?  Because it is not
tied to the code and is not reproducible.  How was the list of
components listed in the wiki generated?  Based on what script?  Where
is the script?  How do we know it is accurate and current?  How do we
know that integrating a CWS does not make that list become outdated?
How do we prove to ourselves that we did this right?  And how to we
record that proof as a record?  And how do we repeat this proof every
time we do a new release?


Questions over questions but not helpful. ;-)


A list of components of unknown derivation sitting on a community wiki
that anyone can edit is not really a suitable basis for an IP review.


Then restrict the write access.


The granularity we need to worry about is the file.  That is the
finest grain level of having a license header.  That is the unit of
tracking in SVN.  That is the unit that someone could have changed the
content in SVN.

Again, it is fine if someone wants to outline this at the module
level.  But that does not eliminate the requirement for us to do this
at the file level as well.


IMHO you haven't understood what I wanted to tell you.

Sure it makes no sense to create a list of every file in SVN to see if 
the license is good or bad. So, do it module by module. And when a 
module is marked as "done", then of course every file in the modules was 
checked. Otherwise it's not working.


And how to make sure that there was no change when source was 
added/moved/improved? Simply Commit Then Review (CTR). A change in the 
license header at the beginning should be remarkable, right? However, we 
also need to have trust in everybodies work.


BTW:
What is your plan to track every file to make sure the license is OK?

Marcus




I can see some brittle cases, especially in the face of refactoring.  The use 
of the wiki might have to be an ephemeral activity that is handled this way 
entirely for our initial scrubbing.

Ideally, additional and sustained review would be in the SVN with the artifacts 
so reviewed, and coalesced somehow.  The use of SVN properties is interesting, 
but they are rather invisible and I have a question about what happens with 
them when a commit happens against the particular artifact.



Properties stick with the file, unless changed.  Think of the
svn:eol-style property.  It is not wiped out with a new revision of
the file.


It seems that there is some need to balance an immediate requirement and what 
would be sufficient for it versus what would assist us in the longer term.  It 
would be interesting to know what the additional-review work has become for 
other projects that have a substantial code base (e.g., SVN itself, httpd, 
...).  I have no idea.



The IP review needs to occur with every release.  So the work we do to
automate this, and make it data-drive, will repay itself with every
release.

I invite you to investigate what other projects do.  When you do I
think you will agree.


  - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org]
Sent: Monday, September 19, 2011 07:47
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?

On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)  wrote:

Am 09/19/2011 01:59 PM, schrieb Rob Weir:


2011/9/19 Jürgen Schmidt:


On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirwrote:


If you haven't looked it closely, it is probably worth a few minutes
of your time to review our incubation status page, especially the
items under "Copyright" and "Verify Distribution Rights".  It lists
the things we need to do, including:

  -- Check and make sure that the papers that transfer rights to the
ASF been received. It is only necessary to transfer rights for the
package, the core code, and any new code produced by the project.

-- Check and make sure that the files that have been donated have been
updated to reflect the new ASF copyright.

-- Check and make sure that for all code included with the
distribution that is not under the Apache license, we have the right
to combine with Apache-licensed code and redistribute.

-- Check and make sure that all source code distributed by the project
is covered by one or more of the following approved licenses: Apache,
BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or someth

Re: A systematic approach to IP review?

[Rob Weir]

On Mon, Sep 19, 2011 at 12:43 PM, Marcus (OOo)  wrote:
> Am 09/19/2011 04:47 PM, schrieb Rob Weir:
>>
>> On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)
>>  wrote:
>>>
>>> Am 09/19/2011 01:59 PM, schrieb Rob Weir:

 2011/9/19 Jürgen Schmidt:
>
> On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir    wrote:
>
>> If you haven't looked it closely, it is probably worth a few minutes
>> of your time to review our incubation status page, especially the
>> items under "Copyright" and "Verify Distribution Rights".  It lists
>> the things we need to do, including:
>>
>>  -- Check and make sure that the papers that transfer rights to the
>> ASF been received. It is only necessary to transfer rights for the
>> package, the core code, and any new code produced by the project.
>>
>> -- Check and make sure that the files that have been donated have been
>> updated to reflect the new ASF copyright.
>>
>> -- Check and make sure that for all code included with the
>> distribution that is not under the Apache license, we have the right
>> to combine with Apache-licensed code and redistribute.
>>
>> -- Check and make sure that all source code distributed by the project
>> is covered by one or more of the following approved licenses: Apache,
>> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
>> the same terms.
>>
>> Some of this is already going on, but it is hard to get a sense of who
>> is doing what and how much progress we have made.  I wonder if we can
>> agree to a more systematic approach?  This will make it easier to see
>> the progress we're making and it will also make it easier for others
>> to help.
>>
>> Suggestions:
>>
>> 1) We need to get all files needed for the build into SVN.  Right now
>> there are some that are copied down from the OpenOffice.org website
>> during the build's bootstrap process.   Until we get the files all in
>> one place it is hard to get a comprehensive view of our dependencies.
>>
>
> do you mean to check in the files under ext_source into svn and remove
> it
> later on when we have cleaned up the code. Or do you mean to put it
> somehwere on apache extras?
> I would prefer to save these binary files under apache extra if
> possible.
>


 Why not just keep in in SVN?   Moving things to Apache-Extras does not
 help us with the IP review.   In other words, if we have a dependency
 on a OSS module that has an incompatible license, then moving that
 module to Apache Extras does not make that dependency go away.  We
 still need to understand the nature of the dependency: a build tool, a
 dynamic runtime dependency, a statically linked library, an optional
 extensions, a necessary core module.

 If we find out, for example, that something in ext-sources is only
 used as a build tool, and is not part of the release, then there is
 nothing that prevents us from hosting it in SVN.   But if something is
 a necessary library and it is under GPL, then this is a problem even
 if we store it on Apache-Extras,


>
>>
>> 2) Continue the CWS integrations.  Along with 1) this ensures that all
>> the code we need for the release is in SVN.
>>
>> 3)  Files that Oracle include in their SGA need to have the Apache
>> license header inserted and the Sun/Oracle copyright migrated to the
>> NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
>> automate parts of this.
>>
>> 4) Once the SGA files have the Apache headers, then we can make
>> regular use of RAT to report on files that are lacking an Apache
>> header.  Such files might be in one of the following categories:
>>
>> a) Files that Oracle owns the copyright on and which should be
>> included in an amended SGA
>>
>> b) Files that have a compatible OSS license which we are permitted to
>> use.  This might require that we add a mention of it to the NOTICE
>> file.
>>
>> c) Files that have an incompatible OSS license.  These need to be
>> removed/replaced.
>>
>> d) Files that have an OSS license that has not yet been
>> reviewed/categorized by Apache legal affairs.  In that case we need to
>> bring it to their attention.
>>
>> e) (Hypothetically) files that are not under an OSS license at all.
>> E.g., a Microsoft header file.  These must be removed.
>>
>> 5) We should to track the resolution of each file, and do this
>> publicly.  The audit trail is important.  Some ways we could do this
>> might be:
>>
>> a) Track this in SVN properties.  So set ip:sga for the SGA files,
>> ip:mit for files that are MIT licensed, etc.  This should be reflected
>> in headers as well, but this is not always possible.  For example, we
>> might have

Re: A systematic approach to IP review?

[Rob Weir]

On Mon, Sep 19, 2011 at 12:35 PM, Dennis E. Hamilton
 wrote:
> Rob,
>
> I was reading the suggestion from Marcus as it being that since the code base 
> is in a folder structure (modularized) and the wiki can map folder structures 
> and their status nicely, it is not necessary to have a single table to manage 
> this from, but have any tables be at some appropriate granularity toward the 
> leaves of the hierarchy (on the wiki).
>

Using the wiki for this might be useful for tracking the status of
modules we already know we need to replace.  Bugzilla would be another
way to track the status.

But it is not really a sufficient solution.  Why?  Because it is not
tied to the code and is not reproducible.  How was the list of
components listed in the wiki generated?  Based on what script?  Where
is the script?  How do we know it is accurate and current?  How do we
know that integrating a CWS does not make that list become outdated?
How do we prove to ourselves that we did this right?  And how to we
record that proof as a record?  And how do we repeat this proof every
time we do a new release?

A list of components of unknown derivation sitting on a community wiki
that anyone can edit is not really a suitable basis for an IP review.

The granularity we need to worry about is the file.  That is the
finest grain level of having a license header.  That is the unit of
tracking in SVN.  That is the unit that someone could have changed the
content in SVN.

Again, it is fine if someone wants to outline this at the module
level.  But that does not eliminate the requirement for us to do this
at the file level as well.

> I can see some brittle cases, especially in the face of refactoring.  The use 
> of the wiki might have to be an ephemeral activity that is handled this way 
> entirely for our initial scrubbing.
>
> Ideally, additional and sustained review would be in the SVN with the 
> artifacts so reviewed, and coalesced somehow.  The use of SVN properties is 
> interesting, but they are rather invisible and I have a question about what 
> happens with them when a commit happens against the particular artifact.
>

Properties stick with the file, unless changed.  Think of the
svn:eol-style property.  It is not wiped out with a new revision of
the file.

> It seems that there is some need to balance an immediate requirement and what 
> would be sufficient for it versus what would assist us in the longer term.  
> It would be interesting to know what the additional-review work has become 
> for other projects that have a substantial code base (e.g., SVN itself, 
> httpd, ...).  I have no idea.
>

The IP review needs to occur with every release.  So the work we do to
automate this, and make it data-drive, will repay itself with every
release.

I invite you to investigate what other projects do.  When you do I
think you will agree.

>  - Dennis
>
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org]
> Sent: Monday, September 19, 2011 07:47
> To: ooo-dev@incubator.apache.org
> Subject: Re: A systematic approach to IP review?
>
> On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)  wrote:
>> Am 09/19/2011 01:59 PM, schrieb Rob Weir:
>>>
>>> 2011/9/19 Jürgen Schmidt:

 On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:

> If you haven't looked it closely, it is probably worth a few minutes
> of your time to review our incubation status page, especially the
> items under "Copyright" and "Verify Distribution Rights".  It lists
> the things we need to do, including:
>
>  -- Check and make sure that the papers that transfer rights to the
> ASF been received. It is only necessary to transfer rights for the
> package, the core code, and any new code produced by the project.
>
> -- Check and make sure that the files that have been donated have been
> updated to reflect the new ASF copyright.
>
> -- Check and make sure that for all code included with the
> distribution that is not under the Apache license, we have the right
> to combine with Apache-licensed code and redistribute.
>
> -- Check and make sure that all source code distributed by the project
> is covered by one or more of the following approved licenses: Apache,
> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
> the same terms.
>
> Some of this is already going on, but it is hard to get a sense of who
> is doing what and how much progress we have made.  I wonder if we can
> agree to a more systematic approach?  This will make it easier to see
> the progress we're making and it will also make it easier for others
> to help.
>
> Suggestions:
>
> 1) We need to get all files needed for the build into SVN.  Right now
> there are some that are copied down from the OpenOffice.org website
> during the build's bootstrap process.   Until we get the files all in
> one place it is hard to get a comprehen

Re: A systematic approach to IP review?

[Marcus (OOo)]

Am 09/19/2011 04:47 PM, schrieb Rob Weir:

On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)  wrote:

Am 09/19/2011 01:59 PM, schrieb Rob Weir:


2011/9/19 Jürgen Schmidt:


On Mon, Sep 19, 2011 at 2:27 AM, Rob Weirwrote:


If you haven't looked it closely, it is probably worth a few minutes
of your time to review our incubation status page, especially the
items under "Copyright" and "Verify Distribution Rights".  It lists
the things we need to do, including:

  -- Check and make sure that the papers that transfer rights to the
ASF been received. It is only necessary to transfer rights for the
package, the core code, and any new code produced by the project.

-- Check and make sure that the files that have been donated have been
updated to reflect the new ASF copyright.

-- Check and make sure that for all code included with the
distribution that is not under the Apache license, we have the right
to combine with Apache-licensed code and redistribute.

-- Check and make sure that all source code distributed by the project
is covered by one or more of the following approved licenses: Apache,
BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
the same terms.

Some of this is already going on, but it is hard to get a sense of who
is doing what and how much progress we have made.  I wonder if we can
agree to a more systematic approach?  This will make it easier to see
the progress we're making and it will also make it easier for others
to help.

Suggestions:

1) We need to get all files needed for the build into SVN.  Right now
there are some that are copied down from the OpenOffice.org website
during the build's bootstrap process.   Until we get the files all in
one place it is hard to get a comprehensive view of our dependencies.



do you mean to check in the files under ext_source into svn and remove it
later on when we have cleaned up the code. Or do you mean to put it
somehwere on apache extras?
I would prefer to save these binary files under apache extra if possible.




Why not just keep in in SVN?   Moving things to Apache-Extras does not
help us with the IP review.   In other words, if we have a dependency
on a OSS module that has an incompatible license, then moving that
module to Apache Extras does not make that dependency go away.  We
still need to understand the nature of the dependency: a build tool, a
dynamic runtime dependency, a statically linked library, an optional
extensions, a necessary core module.

If we find out, for example, that something in ext-sources is only
used as a build tool, and is not part of the release, then there is
nothing that prevents us from hosting it in SVN.   But if something is
a necessary library and it is under GPL, then this is a problem even
if we store it on Apache-Extras,






2) Continue the CWS integrations.  Along with 1) this ensures that all
the code we need for the release is in SVN.

3)  Files that Oracle include in their SGA need to have the Apache
license header inserted and the Sun/Oracle copyright migrated to the
NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
automate parts of this.

4) Once the SGA files have the Apache headers, then we can make
regular use of RAT to report on files that are lacking an Apache
header.  Such files might be in one of the following categories:

a) Files that Oracle owns the copyright on and which should be
included in an amended SGA

b) Files that have a compatible OSS license which we are permitted to
use.  This might require that we add a mention of it to the NOTICE
file.

c) Files that have an incompatible OSS license.  These need to be
removed/replaced.

d) Files that have an OSS license that has not yet been
reviewed/categorized by Apache legal affairs.  In that case we need to
bring it to their attention.

e) (Hypothetically) files that are not under an OSS license at all.
E.g., a Microsoft header file.  These must be removed.

5) We should to track the resolution of each file, and do this
publicly.  The audit trail is important.  Some ways we could do this
might be:

a) Track this in SVN properties.  So set ip:sga for the SGA files,
ip:mit for files that are MIT licensed, etc.  This should be reflected
in headers as well, but this is not always possible.  For example, we
might have binary files where we cannot add headers, or cases where
the OSS files do not have headers, but where we can prove their
provenance via other means.

b) Track this is a spreadsheet, one row per file.

c) Track this is an text log file checked in SVN

d) Track this in an annotated script that runs RAT, where the
annotations document the reason for cases where we tell it to ignore a
file or directory.

6) Iterate until we have a clean RAT report.

7) Goal should be for anyone today to be able to see what work remains
for IP clearance, as well as for someone 5 years from now to be able
to tell what we did.  Tracking this on the community wiki is probably
not good enough, since we've previously talk

RE: A systematic approach to IP review?

[Dennis E. Hamilton]

On the wiki question, I think OOOUSERS should continue to be used for 
transition work.  Or OOODEV could be used if it needs to be limited to 
committers (perhaps the case for this activity), although it means power 
observers can't contribute there and have to do so by some other means.

This is transition work and the Confluence wiki seems like a good place for it.

The MW may be interrupted or disrupted and it is probably a good idea to *not* 
put such development-transition intensive content there.  

Also, "the migrated wiki" is not the live wiki at OpenOffice.org.  So doing 
anything there will create collisions.  It is also not fully migrated in that 
it is not operating in place of what folks see via OpenOffice.org as far as I 
know.  The current Confluence wikis avoid confusion and are stable for this 
particular purpose.

 - Dennis



-Original Message-
From: Jürgen Schmidt [mailto:jogischm...@googlemail.com] 
Sent: Monday, September 19, 2011 01:45
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?

On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:

[ ... ]

> 7) Goal should be for anyone today to be able to see what work remains
> for IP clearance, as well as for someone 5 years from now to be able
> to tell what we did.  Tracking this on the community wiki is probably
> not good enough, since we've previously talked about dropping that
> wiki and going to MWiki.
>

talked about it yes but did we reached a final decision?

The migrated wiki is available under http://ooo-wiki.apache.org/wiki and can
be used. Do we want to continue with this wiki now? It's still not clear for
me at the moment.

[ ... ]

RE: A systematic approach to IP review?

[Dennis E. Hamilton]

Rob,

I was reading the suggestion from Marcus as it being that since the code base 
is in a folder structure (modularized) and the wiki can map folder structures 
and their status nicely, it is not necessary to have a single table to manage 
this from, but have any tables be at some appropriate granularity toward the 
leaves of the hierarchy (on the wiki).

I can see some brittle cases, especially in the face of refactoring.  The use 
of the wiki might have to be an ephemeral activity that is handled this way 
entirely for our initial scrubbing.

Ideally, additional and sustained review would be in the SVN with the artifacts 
so reviewed, and coalesced somehow.  The use of SVN properties is interesting, 
but they are rather invisible and I have a question about what happens with 
them when a commit happens against the particular artifact.

It seems that there is some need to balance an immediate requirement and what 
would be sufficient for it versus what would assist us in the longer term.  It 
would be interesting to know what the additional-review work has become for 
other projects that have a substantial code base (e.g., SVN itself, httpd, 
...).  I have no idea.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Monday, September 19, 2011 07:47
To: ooo-dev@incubator.apache.org
Subject: Re: A systematic approach to IP review?

On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)  wrote:
> Am 09/19/2011 01:59 PM, schrieb Rob Weir:
>>
>> 2011/9/19 Jürgen Schmidt:
>>>
>>> On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:
>>>
 If you haven't looked it closely, it is probably worth a few minutes
 of your time to review our incubation status page, especially the
 items under "Copyright" and "Verify Distribution Rights".  It lists
 the things we need to do, including:

  -- Check and make sure that the papers that transfer rights to the
 ASF been received. It is only necessary to transfer rights for the
 package, the core code, and any new code produced by the project.

 -- Check and make sure that the files that have been donated have been
 updated to reflect the new ASF copyright.

 -- Check and make sure that for all code included with the
 distribution that is not under the Apache license, we have the right
 to combine with Apache-licensed code and redistribute.

 -- Check and make sure that all source code distributed by the project
 is covered by one or more of the following approved licenses: Apache,
 BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
 the same terms.

 Some of this is already going on, but it is hard to get a sense of who
 is doing what and how much progress we have made.  I wonder if we can
 agree to a more systematic approach?  This will make it easier to see
 the progress we're making and it will also make it easier for others
 to help.

 Suggestions:

 1) We need to get all files needed for the build into SVN.  Right now
 there are some that are copied down from the OpenOffice.org website
 during the build's bootstrap process.   Until we get the files all in
 one place it is hard to get a comprehensive view of our dependencies.

>>>
>>> do you mean to check in the files under ext_source into svn and remove it
>>> later on when we have cleaned up the code. Or do you mean to put it
>>> somehwere on apache extras?
>>> I would prefer to save these binary files under apache extra if possible.
>>>
>>
>>
>> Why not just keep in in SVN?   Moving things to Apache-Extras does not
>> help us with the IP review.   In other words, if we have a dependency
>> on a OSS module that has an incompatible license, then moving that
>> module to Apache Extras does not make that dependency go away.  We
>> still need to understand the nature of the dependency: a build tool, a
>> dynamic runtime dependency, a statically linked library, an optional
>> extensions, a necessary core module.
>>
>> If we find out, for example, that something in ext-sources is only
>> used as a build tool, and is not part of the release, then there is
>> nothing that prevents us from hosting it in SVN.   But if something is
>> a necessary library and it is under GPL, then this is a problem even
>> if we store it on Apache-Extras,
>>
>>
>>>

 2) Continue the CWS integrations.  Along with 1) this ensures that all
 the code we need for the release is in SVN.

 3)  Files that Oracle include in their SGA need to have the Apache
 license header inserted and the Sun/Oracle copyright migrated to the
 NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
 automate parts of this.

 4) Once the SGA files have the Apache headers, then we can make
 regular use of RAT to report on files that are lacking an Apache
 header.  Such files might be in one of the following categories:

 a) Files that

Re: A systematic approach to IP review?

[Pedro F. Giffuni]

--- On Mon, 9/19/11, Rob Weir  wrote:
...
> 2011/9/19 Jürgen Schmidt :
...
> >
> > do you mean to check in the files under ext_source
> into svn and remove it
> > later on when we have cleaned up the code. Or do you
> mean to put it
> > somehwere on apache extras?
> > I would prefer to save these binary files under apache
> extra if possible.
> >
> 
> 
> Why not just keep in in SVN?   Moving things
> to Apache-Extras does not
> help us with the IP review.   In other
> words, if we have a dependency
> on a OSS module that has an incompatible license, then
> moving that
> module to Apache Extras does not make that dependency go
> away.  We
> still need to understand the nature of the dependency: a
> build tool, a
> dynamic runtime dependency, a statically linked library, an
> optional
> extensions, a necessary core module.
>

But adding in stuff that we have to remove immediately (nss,
seamonkey, .. ) doesn't help either. I also think a lot of
that stuff has to be updated before brought in: ICU
apparently would be trouble, but the Apache-commons, ICC,
and other stuff can/should be updated.



>> a) Track this in SVN properties.  So set ip:sga
> for the SGA files,
> >> ip:mit for files that are MIT licensed, etc.


I thought we had delayed updating the copyrights in the
header to ease the CWS integration. I still hope to see
more of those, especially anything related to gnumake
(I don't know when, but dmake has to go!).

Using the SVN properties is a good idea. And we do have
to start the NOTICES file.

All just IMHO, of course.

Pedro.

Re: A systematic approach to IP review?

[Rob Weir]

On Mon, Sep 19, 2011 at 8:13 AM, Marcus (OOo)  wrote:
> Am 09/19/2011 01:59 PM, schrieb Rob Weir:
>>
>> 2011/9/19 Jürgen Schmidt:
>>>
>>> On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:
>>>
 If you haven't looked it closely, it is probably worth a few minutes
 of your time to review our incubation status page, especially the
 items under "Copyright" and "Verify Distribution Rights".  It lists
 the things we need to do, including:

  -- Check and make sure that the papers that transfer rights to the
 ASF been received. It is only necessary to transfer rights for the
 package, the core code, and any new code produced by the project.

 -- Check and make sure that the files that have been donated have been
 updated to reflect the new ASF copyright.

 -- Check and make sure that for all code included with the
 distribution that is not under the Apache license, we have the right
 to combine with Apache-licensed code and redistribute.

 -- Check and make sure that all source code distributed by the project
 is covered by one or more of the following approved licenses: Apache,
 BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
 the same terms.

 Some of this is already going on, but it is hard to get a sense of who
 is doing what and how much progress we have made.  I wonder if we can
 agree to a more systematic approach?  This will make it easier to see
 the progress we're making and it will also make it easier for others
 to help.

 Suggestions:

 1) We need to get all files needed for the build into SVN.  Right now
 there are some that are copied down from the OpenOffice.org website
 during the build's bootstrap process.   Until we get the files all in
 one place it is hard to get a comprehensive view of our dependencies.

>>>
>>> do you mean to check in the files under ext_source into svn and remove it
>>> later on when we have cleaned up the code. Or do you mean to put it
>>> somehwere on apache extras?
>>> I would prefer to save these binary files under apache extra if possible.
>>>
>>
>>
>> Why not just keep in in SVN?   Moving things to Apache-Extras does not
>> help us with the IP review.   In other words, if we have a dependency
>> on a OSS module that has an incompatible license, then moving that
>> module to Apache Extras does not make that dependency go away.  We
>> still need to understand the nature of the dependency: a build tool, a
>> dynamic runtime dependency, a statically linked library, an optional
>> extensions, a necessary core module.
>>
>> If we find out, for example, that something in ext-sources is only
>> used as a build tool, and is not part of the release, then there is
>> nothing that prevents us from hosting it in SVN.   But if something is
>> a necessary library and it is under GPL, then this is a problem even
>> if we store it on Apache-Extras,
>>
>>
>>>

 2) Continue the CWS integrations.  Along with 1) this ensures that all
 the code we need for the release is in SVN.

 3)  Files that Oracle include in their SGA need to have the Apache
 license header inserted and the Sun/Oracle copyright migrated to the
 NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
 automate parts of this.

 4) Once the SGA files have the Apache headers, then we can make
 regular use of RAT to report on files that are lacking an Apache
 header.  Such files might be in one of the following categories:

 a) Files that Oracle owns the copyright on and which should be
 included in an amended SGA

 b) Files that have a compatible OSS license which we are permitted to
 use.  This might require that we add a mention of it to the NOTICE
 file.

 c) Files that have an incompatible OSS license.  These need to be
 removed/replaced.

 d) Files that have an OSS license that has not yet been
 reviewed/categorized by Apache legal affairs.  In that case we need to
 bring it to their attention.

 e) (Hypothetically) files that are not under an OSS license at all.
 E.g., a Microsoft header file.  These must be removed.

 5) We should to track the resolution of each file, and do this
 publicly.  The audit trail is important.  Some ways we could do this
 might be:

 a) Track this in SVN properties.  So set ip:sga for the SGA files,
 ip:mit for files that are MIT licensed, etc.  This should be reflected
 in headers as well, but this is not always possible.  For example, we
 might have binary files where we cannot add headers, or cases where
 the OSS files do not have headers, but where we can prove their
 provenance via other means.

 b) Track this is a spreadsheet, one row per file.

 c) Track this is an text log file checked in SVN

 d) Track this in an annotated script that

Re: automake insteed configure

[Herbert Duerr]

In the past, configure was only rebuild if needed by samone (releng?) in
Hamburg. Now Mathias Bauer recommends to build configure.sh everytime
and make automake to the default step by the buildprocess. I think this
Step should be don ASAP.
I think that's not a load of changes, but I have a question: "How to run
automake, and where it is located" can sameone help me.


You probably mean "autoconf", right?

If you are on windows install the autoconf package from cygwin. If you 
are on Linux install it from your package repository.


Herbert

Re: A systematic approach to IP review?

[Marcus (OOo)]

Am 09/19/2011 01:59 PM, schrieb Rob Weir:

2011/9/19 Jürgen Schmidt:

On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:


If you haven't looked it closely, it is probably worth a few minutes
of your time to review our incubation status page, especially the
items under "Copyright" and "Verify Distribution Rights".  It lists
the things we need to do, including:

  -- Check and make sure that the papers that transfer rights to the
ASF been received. It is only necessary to transfer rights for the
package, the core code, and any new code produced by the project.

-- Check and make sure that the files that have been donated have been
updated to reflect the new ASF copyright.

-- Check and make sure that for all code included with the
distribution that is not under the Apache license, we have the right
to combine with Apache-licensed code and redistribute.

-- Check and make sure that all source code distributed by the project
is covered by one or more of the following approved licenses: Apache,
BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
the same terms.

Some of this is already going on, but it is hard to get a sense of who
is doing what and how much progress we have made.  I wonder if we can
agree to a more systematic approach?  This will make it easier to see
the progress we're making and it will also make it easier for others
to help.

Suggestions:

1) We need to get all files needed for the build into SVN.  Right now
there are some that are copied down from the OpenOffice.org website
during the build's bootstrap process.   Until we get the files all in
one place it is hard to get a comprehensive view of our dependencies.



do you mean to check in the files under ext_source into svn and remove it
later on when we have cleaned up the code. Or do you mean to put it
somehwere on apache extras?
I would prefer to save these binary files under apache extra if possible.




Why not just keep in in SVN?   Moving things to Apache-Extras does not
help us with the IP review.   In other words, if we have a dependency
on a OSS module that has an incompatible license, then moving that
module to Apache Extras does not make that dependency go away.  We
still need to understand the nature of the dependency: a build tool, a
dynamic runtime dependency, a statically linked library, an optional
extensions, a necessary core module.

If we find out, for example, that something in ext-sources is only
used as a build tool, and is not part of the release, then there is
nothing that prevents us from hosting it in SVN.   But if something is
a necessary library and it is under GPL, then this is a problem even
if we store it on Apache-Extras,






2) Continue the CWS integrations.  Along with 1) this ensures that all
the code we need for the release is in SVN.

3)  Files that Oracle include in their SGA need to have the Apache
license header inserted and the Sun/Oracle copyright migrated to the
NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
automate parts of this.

4) Once the SGA files have the Apache headers, then we can make
regular use of RAT to report on files that are lacking an Apache
header.  Such files might be in one of the following categories:

a) Files that Oracle owns the copyright on and which should be
included in an amended SGA

b) Files that have a compatible OSS license which we are permitted to
use.  This might require that we add a mention of it to the NOTICE
file.

c) Files that have an incompatible OSS license.  These need to be
removed/replaced.

d) Files that have an OSS license that has not yet been
reviewed/categorized by Apache legal affairs.  In that case we need to
bring it to their attention.

e) (Hypothetically) files that are not under an OSS license at all.
E.g., a Microsoft header file.  These must be removed.

5) We should to track the resolution of each file, and do this
publicly.  The audit trail is important.  Some ways we could do this
might be:

a) Track this in SVN properties.  So set ip:sga for the SGA files,
ip:mit for files that are MIT licensed, etc.  This should be reflected
in headers as well, but this is not always possible.  For example, we
might have binary files where we cannot add headers, or cases where
the OSS files do not have headers, but where we can prove their
provenance via other means.

b) Track this is a spreadsheet, one row per file.

c) Track this is an text log file checked in SVN

d) Track this in an annotated script that runs RAT, where the
annotations document the reason for cases where we tell it to ignore a
file or directory.

6) Iterate until we have a clean RAT report.

7) Goal should be for anyone today to be able to see what work remains
for IP clearance, as well as for someone 5 years from now to be able
to tell what we did.  Tracking this on the community wiki is probably
not good enough, since we've previously talked about dropping that
wiki and going to MWiki.



talked about it yes but did we reached a final deci

Re: A systematic approach to IP review?

[Rob Weir]

2011/9/19 Jürgen Schmidt :
> On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:
>
>> If you haven't looked it closely, it is probably worth a few minutes
>> of your time to review our incubation status page, especially the
>> items under "Copyright" and "Verify Distribution Rights".  It lists
>> the things we need to do, including:
>>
>>  -- Check and make sure that the papers that transfer rights to the
>> ASF been received. It is only necessary to transfer rights for the
>> package, the core code, and any new code produced by the project.
>>
>> -- Check and make sure that the files that have been donated have been
>> updated to reflect the new ASF copyright.
>>
>> -- Check and make sure that for all code included with the
>> distribution that is not under the Apache license, we have the right
>> to combine with Apache-licensed code and redistribute.
>>
>> -- Check and make sure that all source code distributed by the project
>> is covered by one or more of the following approved licenses: Apache,
>> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
>> the same terms.
>>
>> Some of this is already going on, but it is hard to get a sense of who
>> is doing what and how much progress we have made.  I wonder if we can
>> agree to a more systematic approach?  This will make it easier to see
>> the progress we're making and it will also make it easier for others
>> to help.
>>
>> Suggestions:
>>
>> 1) We need to get all files needed for the build into SVN.  Right now
>> there are some that are copied down from the OpenOffice.org website
>> during the build's bootstrap process.   Until we get the files all in
>> one place it is hard to get a comprehensive view of our dependencies.
>>
>
> do you mean to check in the files under ext_source into svn and remove it
> later on when we have cleaned up the code. Or do you mean to put it
> somehwere on apache extras?
> I would prefer to save these binary files under apache extra if possible.
>


Why not just keep in in SVN?   Moving things to Apache-Extras does not
help us with the IP review.   In other words, if we have a dependency
on a OSS module that has an incompatible license, then moving that
module to Apache Extras does not make that dependency go away.  We
still need to understand the nature of the dependency: a build tool, a
dynamic runtime dependency, a statically linked library, an optional
extensions, a necessary core module.

If we find out, for example, that something in ext-sources is only
used as a build tool, and is not part of the release, then there is
nothing that prevents us from hosting it in SVN.   But if something is
a necessary library and it is under GPL, then this is a problem even
if we store it on Apache-Extras,


>
>>
>> 2) Continue the CWS integrations.  Along with 1) this ensures that all
>> the code we need for the release is in SVN.
>>
>> 3)  Files that Oracle include in their SGA need to have the Apache
>> license header inserted and the Sun/Oracle copyright migrated to the
>> NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
>> automate parts of this.
>>
>> 4) Once the SGA files have the Apache headers, then we can make
>> regular use of RAT to report on files that are lacking an Apache
>> header.  Such files might be in one of the following categories:
>>
>> a) Files that Oracle owns the copyright on and which should be
>> included in an amended SGA
>>
>> b) Files that have a compatible OSS license which we are permitted to
>> use.  This might require that we add a mention of it to the NOTICE
>> file.
>>
>> c) Files that have an incompatible OSS license.  These need to be
>> removed/replaced.
>>
>> d) Files that have an OSS license that has not yet been
>> reviewed/categorized by Apache legal affairs.  In that case we need to
>> bring it to their attention.
>>
>> e) (Hypothetically) files that are not under an OSS license at all.
>> E.g., a Microsoft header file.  These must be removed.
>>
>> 5) We should to track the resolution of each file, and do this
>> publicly.  The audit trail is important.  Some ways we could do this
>> might be:
>>
>> a) Track this in SVN properties.  So set ip:sga for the SGA files,
>> ip:mit for files that are MIT licensed, etc.  This should be reflected
>> in headers as well, but this is not always possible.  For example, we
>> might have binary files where we cannot add headers, or cases where
>> the OSS files do not have headers, but where we can prove their
>> provenance via other means.
>>
>> b) Track this is a spreadsheet, one row per file.
>>
>> c) Track this is an text log file checked in SVN
>>
>> d) Track this in an annotated script that runs RAT, where the
>> annotations document the reason for cases where we tell it to ignore a
>> file or directory.
>>
>> 6) Iterate until we have a clean RAT report.
>>
>> 7) Goal should be for anyone today to be able to see what work remains
>> for IP clearance, as well as for someone 5 years from now to be able
>> to tell wha

Re: A systematic approach to IP review?

[Rob Weir]

On Sun, Sep 18, 2011 at 9:34 PM, Pedro Giffuni  wrote:
> Hi;
>
> Is there an updated SGA already?
>

Not that I know of.   But we can and should go ahead with IP clearance
using the SGA we already have.   In fact, starting that process will
help us identify exactly which files needed to be added to the updated
SGA.

-Rob


> I think there will likely be a set of files of uncertain license
> that we should move to apache-extras. I am refering specifically
> to the dictionaries: Oracle might have property over some but not
> all. I propose we rescue myspell in apache-extras and put the
> dictionaries there to keep it as an alternative. I have no idea
> where to get MySpell though.
>
> While here, if there's still interest in maintaining the Hg
> history, bitbucket.org seems to be a nice alternative: it's
> rather specialized in Mercurial.
>
> Cheers,
>
> Pedro.
>
> On Sun, 18 Sep 2011 20:27:05 -0400, Rob Weir  wrote:
>>
>> If you haven't looked it closely, it is probably worth a few minutes
>> of your time to review our incubation status page, especially the
>> items under "Copyright" and "Verify Distribution Rights".  It lists
>> the things we need to do, including:
>>
>>  -- Check and make sure that the papers that transfer rights to the
>> ASF been received. It is only necessary to transfer rights for the
>> package, the core code, and any new code produced by the project.
>>
>> -- Check and make sure that the files that have been donated have been
>> updated to reflect the new ASF copyright.
>>
>> -- Check and make sure that for all code included with the
>> distribution that is not under the Apache license, we have the right
>> to combine with Apache-licensed code and redistribute.
>>
>> -- Check and make sure that all source code distributed by the project
>> is covered by one or more of the following approved licenses: Apache,
>> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
>> the same terms.
>>
>> Some of this is already going on, but it is hard to get a sense of who
>> is doing what and how much progress we have made.  I wonder if we can
>> agree to a more systematic approach?  This will make it easier to see
>> the progress we're making and it will also make it easier for others
>> to help.
>>
>> Suggestions:
>>
>> 1) We need to get all files needed for the build into SVN.  Right now
>> there are some that are copied down from the OpenOffice.org website
>> during the build's bootstrap process.   Until we get the files all in
>> one place it is hard to get a comprehensive view of our dependencies.
>>
>> 2) Continue the CWS integrations.  Along with 1) this ensures that all
>> the code we need for the release is in SVN.
>>
>> 3)  Files that Oracle include in their SGA need to have the Apache
>> license header inserted and the Sun/Oracle copyright migrated to the
>> NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
>> automate parts of this.
>>
>> 4) Once the SGA files have the Apache headers, then we can make
>> regular use of RAT to report on files that are lacking an Apache
>> header.  Such files might be in one of the following categories:
>>
>> a) Files that Oracle owns the copyright on and which should be
>> included in an amended SGA
>>
>> b) Files that have a compatible OSS license which we are permitted to
>> use.  This might require that we add a mention of it to the NOTICE
>> file.
>>
>> c) Files that have an incompatible OSS license.  These need to be
>> removed/replaced.
>>
>> d) Files that have an OSS license that has not yet been
>> reviewed/categorized by Apache legal affairs.  In that case we need to
>> bring it to their attention.
>>
>> e) (Hypothetically) files that are not under an OSS license at all.
>> E.g., a Microsoft header file.  These must be removed.
>>
>> 5) We should to track the resolution of each file, and do this
>> publicly.  The audit trail is important.  Some ways we could do this
>> might be:
>>
>> a) Track this in SVN properties.  So set ip:sga for the SGA files,
>> ip:mit for files that are MIT licensed, etc.  This should be reflected
>> in headers as well, but this is not always possible.  For example, we
>> might have binary files where we cannot add headers, or cases where
>> the OSS files do not have headers, but where we can prove their
>> provenance via other means.
>>
>> b) Track this is a spreadsheet, one row per file.
>>
>> c) Track this is an text log file checked in SVN
>>
>> d) Track this in an annotated script that runs RAT, where the
>> annotations document the reason for cases where we tell it to ignore a
>> file or directory.
>>
>> 6) Iterate until we have a clean RAT report.
>>
>> 7) Goal should be for anyone today to be able to see what work remains
>> for IP clearance, as well as for someone 5 years from now to be able
>> to tell what we did.  Tracking this on the community wiki is probably
>> not good enough, since we've previously talked about dropping that
>> wiki and going to MWiki.
>>
>>
>> -Rob
>>
>

automake insteed configure

[Raphael Bircher]

Hi all

In the past, configure was only rebuild if needed by samone (releng?) in 
Hamburg. Now Mathias Bauer recommends to build configure.sh everytime 
and make automake to the default step by the buildprocess. I think this 
Step should be don ASAP.
I think that's not a load of changes, but I have a question: "How to run 
automake, and where it is located" can sameone help me.


Thanks a load

Greetings
Raphael
--
My private Homepage: http://www.raphaelbircher.ch/

Re: VCL TestTool

[Raphael Bircher]

Hi Frank

Am 19.09.11 09:26, schrieb Frank Schönheit:

Hi Mathias,


- fix the testtool code in the "automation" module and try to create a
newer and better version of it.

which is what I'd prefer. On the medium run, I'd even be more agressive:
Replace the current test tool with something else, offering the same
functionality. In particular, I'd like to see Java support for writing
GUI tests. This would have several advantages:
- No need to maintain a dedicated TestTool IDE - any Java IDE would do.
- No need to write test scripts in this awkward Bssic flavour
- Easier to add additional functionality to the testtool

by chance :), I started something like this 2 years or so ago, back in
HH times. I have still some code which implements (part of) the protocol
used by the testtool, and allows (the very beginning of) OOo GUI
automation in Java.

Actually, I am not sure whether reusing the existing protocol is a good
idea at all. Perhaps we should just re-use the existing command server
code in OOo, and re-implement the socket protocol in a more modern way,
together with a new client. Don't know enough 'bout the internals to
really judge this.

In any way, I'd be happy already if those Basic scripts could be replace
by something more 21st-century-like.
All good Ideas, but we should not investegate blind too much time in the 
TT. We realy need to evaluate, what's the benefit, and how much time it 
cost. It's a difference if we find 10 Regression or 500 in one year with 
the TT. So the first thing is to see how much time TT save for QA.


In general, I'm for automated testing, because this is a good method to 
find regressions. Skilled QA people are rare, so they should not waste 
time with manual testing to avoind regression. They should have time for 
intuitive testing of new features. If a testrun of 1 day computer time 
takes 20 minute for a QA to analyze the Results, it is probaly a big 
benefit. But if you need 2 houers to analyze it's maybe not wroth to 
maintain the TT and all the scripts.


So let us first see, what's the real benefit of the testtool.

Greetings
Raphael



Ciao
Frank




--
My private Homepage: http://www.raphaelbircher.ch/

Re: Wiki in productive use? was: A systematic approach to IP review?

[Raphael Bircher]

Hi Jürgen

Am 19.09.11 10:44, schrieb Jürgen Schmidt:
7) Goal should be for anyone today to be able to see what work remains 
for IP clearance, as well as for someone 5 years from now to be able 
to tell what we did. Tracking this on the community wiki is probably 
not good enough, since we've previously talked about dropping that 
wiki and going to MWiki.

talked about it yes but did we reached a final decision?

The migrated wiki is available under http://ooo-wiki.apache.org/wiki and can
be used. Do we want to continue with this wiki now? It's still not clear for
me at the moment.

But we need a place to document the IP clearance and under
http://ooo-wiki.apache.org/wiki/ApacheMigration we have already some
information.
As I know, the wiki is not in productive us yet. We have first to ask 
the infra for the go! And than to switch the dns from wiki services to 
ooo-wiki.apache.org. I take Infrastructure into the mail


Greetings Raphael




Juergen






--
My private Homepage: http://www.raphaelbircher.ch/

Re: about performance project

[tianbo]

Hi all
Performance , which is relate to User Experience , is so important that I am 
very glad to work on it. 
In general, I am going to estimate most frequently used functions' performance. 
With the help of the result , 
developers can improve the performance by modifying the slow functions.
I have several ideas about AOOo Performance . The initial thoughts is as follow:
First, insert some benchmarks into AOOo to log the timestamps. Try most 
functions several times to get the timestamps. 
Second, analyse the timestamps , calculate the average time every function 
cost, which is an original reference and Initial results.
Third, according to the UEI( User Experience Index :See also 
http://wiki.services.openoffice.org/wiki/UEI)  ,
give every module a score of weight. Calculate the total score OOo get and 
compare it among different OOo versions.
Of course I wish all of the mentioned steps can be done as automatically as 
possible. 
Finally, it may become a performance estimating tool of OOo just like 3Dmarks 
to video cards.
I may need your technically support and I am expecting your better ideas.




Tian Bo
Software Developer 

Beijing Redflag Chinese 2000 Software Co., Ltd.
Building No.2, Block A, Huilongsen, 18 Xihuan Nanlu
Beijing Economic-Technological Development Area
100176 Beijing - P.R.China


北京红旗中文贰仟软件技术有限公司
地址：北京经济技术开发区（亦庄）西环南路18号汇龙森A座二层
邮编/PostCode：100176
电话/Tel: +86-10-51570010 ext.6194
邮箱/e-mail： tia...@300.cn 
http://www.RedOffice.com 

Re: A systematic approach to IP review?

[Jürgen Schmidt]

On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir  wrote:

> If you haven't looked it closely, it is probably worth a few minutes
> of your time to review our incubation status page, especially the
> items under "Copyright" and "Verify Distribution Rights".  It lists
> the things we need to do, including:
>
>  -- Check and make sure that the papers that transfer rights to the
> ASF been received. It is only necessary to transfer rights for the
> package, the core code, and any new code produced by the project.
>
> -- Check and make sure that the files that have been donated have been
> updated to reflect the new ASF copyright.
>
> -- Check and make sure that for all code included with the
> distribution that is not under the Apache license, we have the right
> to combine with Apache-licensed code and redistribute.
>
> -- Check and make sure that all source code distributed by the project
> is covered by one or more of the following approved licenses: Apache,
> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
> the same terms.
>
> Some of this is already going on, but it is hard to get a sense of who
> is doing what and how much progress we have made.  I wonder if we can
> agree to a more systematic approach?  This will make it easier to see
> the progress we're making and it will also make it easier for others
> to help.
>
> Suggestions:
>
> 1) We need to get all files needed for the build into SVN.  Right now
> there are some that are copied down from the OpenOffice.org website
> during the build's bootstrap process.   Until we get the files all in
> one place it is hard to get a comprehensive view of our dependencies.
>

do you mean to check in the files under ext_source into svn and remove it
later on when we have cleaned up the code. Or do you mean to put it
somehwere on apache extras?
I would prefer to save these binary files under apache extra if possible.


>
> 2) Continue the CWS integrations.  Along with 1) this ensures that all
> the code we need for the release is in SVN.
>
> 3)  Files that Oracle include in their SGA need to have the Apache
> license header inserted and the Sun/Oracle copyright migrated to the
> NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
> automate parts of this.
>
> 4) Once the SGA files have the Apache headers, then we can make
> regular use of RAT to report on files that are lacking an Apache
> header.  Such files might be in one of the following categories:
>
> a) Files that Oracle owns the copyright on and which should be
> included in an amended SGA
>
> b) Files that have a compatible OSS license which we are permitted to
> use.  This might require that we add a mention of it to the NOTICE
> file.
>
> c) Files that have an incompatible OSS license.  These need to be
> removed/replaced.
>
> d) Files that have an OSS license that has not yet been
> reviewed/categorized by Apache legal affairs.  In that case we need to
> bring it to their attention.
>
> e) (Hypothetically) files that are not under an OSS license at all.
> E.g., a Microsoft header file.  These must be removed.
>
> 5) We should to track the resolution of each file, and do this
> publicly.  The audit trail is important.  Some ways we could do this
> might be:
>
> a) Track this in SVN properties.  So set ip:sga for the SGA files,
> ip:mit for files that are MIT licensed, etc.  This should be reflected
> in headers as well, but this is not always possible.  For example, we
> might have binary files where we cannot add headers, or cases where
> the OSS files do not have headers, but where we can prove their
> provenance via other means.
>
> b) Track this is a spreadsheet, one row per file.
>
> c) Track this is an text log file checked in SVN
>
> d) Track this in an annotated script that runs RAT, where the
> annotations document the reason for cases where we tell it to ignore a
> file or directory.
>
> 6) Iterate until we have a clean RAT report.
>
> 7) Goal should be for anyone today to be able to see what work remains
> for IP clearance, as well as for someone 5 years from now to be able
> to tell what we did.  Tracking this on the community wiki is probably
> not good enough, since we've previously talked about dropping that
> wiki and going to MWiki.
>

talked about it yes but did we reached a final decision?

The migrated wiki is available under http://ooo-wiki.apache.org/wiki and can
be used. Do we want to continue with this wiki now? It's still not clear for
me at the moment.

But we need a place to document the IP clearance and under
http://ooo-wiki.apache.org/wiki/ApacheMigration we have already some
information.

Juergen


>
>
> -Rob
>
>
> [1] http://incubator.apache.org/projects/openofficeorg.html
>
> [2] http://incubator.apache.org/rat/
>

Re: A systematic approach to IP review?

[Jürgen Schmidt]

On Mon, Sep 19, 2011 at 3:34 AM, Pedro Giffuni  wrote:

> Hi;
>
> Is there an updated SGA already?
>

good question and where can we find it?

Juergen


>
> I think there will likely be a set of files of uncertain license
> that we should move to apache-extras. I am refering specifically
> to the dictionaries: Oracle might have property over some but not
> all. I propose we rescue myspell in apache-extras and put the
> dictionaries there to keep it as an alternative. I have no idea
> where to get MySpell though.
>
> While here, if there's still interest in maintaining the Hg
> history, bitbucket.org seems to be a nice alternative: it's
> rather specialized in Mercurial.
>
> Cheers,
>
> Pedro.
>
>
> On Sun, 18 Sep 2011 20:27:05 -0400, Rob Weir  wrote:
>
>> If you haven't looked it closely, it is probably worth a few minutes
>> of your time to review our incubation status page, especially the
>> items under "Copyright" and "Verify Distribution Rights".  It lists
>> the things we need to do, including:
>>
>>  -- Check and make sure that the papers that transfer rights to the
>> ASF been received. It is only necessary to transfer rights for the
>> package, the core code, and any new code produced by the project.
>>
>> -- Check and make sure that the files that have been donated have been
>> updated to reflect the new ASF copyright.
>>
>> -- Check and make sure that for all code included with the
>> distribution that is not under the Apache license, we have the right
>> to combine with Apache-licensed code and redistribute.
>>
>> -- Check and make sure that all source code distributed by the project
>> is covered by one or more of the following approved licenses: Apache,
>> BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially
>> the same terms.
>>
>> Some of this is already going on, but it is hard to get a sense of who
>> is doing what and how much progress we have made.  I wonder if we can
>> agree to a more systematic approach?  This will make it easier to see
>> the progress we're making and it will also make it easier for others
>> to help.
>>
>> Suggestions:
>>
>> 1) We need to get all files needed for the build into SVN.  Right now
>> there are some that are copied down from the OpenOffice.org website
>> during the build's bootstrap process.   Until we get the files all in
>> one place it is hard to get a comprehensive view of our dependencies.
>>
>> 2) Continue the CWS integrations.  Along with 1) this ensures that all
>> the code we need for the release is in SVN.
>>
>> 3)  Files that Oracle include in their SGA need to have the Apache
>> license header inserted and the Sun/Oracle copyright migrated to the
>> NOTICE file.  Apache RAT (Release Audit Tool) [2] can be used to
>> automate parts of this.
>>
>> 4) Once the SGA files have the Apache headers, then we can make
>> regular use of RAT to report on files that are lacking an Apache
>> header.  Such files might be in one of the following categories:
>>
>> a) Files that Oracle owns the copyright on and which should be
>> included in an amended SGA
>>
>> b) Files that have a compatible OSS license which we are permitted to
>> use.  This might require that we add a mention of it to the NOTICE
>> file.
>>
>> c) Files that have an incompatible OSS license.  These need to be
>> removed/replaced.
>>
>> d) Files that have an OSS license that has not yet been
>> reviewed/categorized by Apache legal affairs.  In that case we need to
>> bring it to their attention.
>>
>> e) (Hypothetically) files that are not under an OSS license at all.
>> E.g., a Microsoft header file.  These must be removed.
>>
>> 5) We should to track the resolution of each file, and do this
>> publicly.  The audit trail is important.  Some ways we could do this
>> might be:
>>
>> a) Track this in SVN properties.  So set ip:sga for the SGA files,
>> ip:mit for files that are MIT licensed, etc.  This should be reflected
>> in headers as well, but this is not always possible.  For example, we
>> might have binary files where we cannot add headers, or cases where
>> the OSS files do not have headers, but where we can prove their
>> provenance via other means.
>>
>> b) Track this is a spreadsheet, one row per file.
>>
>> c) Track this is an text log file checked in SVN
>>
>> d) Track this in an annotated script that runs RAT, where the
>> annotations document the reason for cases where we tell it to ignore a
>> file or directory.
>>
>> 6) Iterate until we have a clean RAT report.
>>
>> 7) Goal should be for anyone today to be able to see what work remains
>> for IP clearance, as well as for someone 5 years from now to be able
>> to tell what we did.  Tracking this on the community wiki is probably
>> not good enough, since we've previously talked about dropping that
>> wiki and going to MWiki.
>>
>>
>> -Rob
>>
>>
>> [1] 
>> http://incubator.apache.org/**projects/openofficeorg.html
>>
>> [2] http://incubator.apache.org/**r

Re: VCL TestTool

[Frank Schönheit]

Hi Mathias,

> - fix the testtool code in the "automation" module and try to create a
> newer and better version of it.

which is what I'd prefer. On the medium run, I'd even be more agressive:
Replace the current test tool with something else, offering the same
functionality. In particular, I'd like to see Java support for writing
GUI tests. This would have several advantages:
- No need to maintain a dedicated TestTool IDE - any Java IDE would do.
- No need to write test scripts in this awkward Bssic flavour
- Easier to add additional functionality to the testtool

by chance :), I started something like this 2 years or so ago, back in
HH times. I have still some code which implements (part of) the protocol
used by the testtool, and allows (the very beginning of) OOo GUI
automation in Java.

Actually, I am not sure whether reusing the existing protocol is a good
idea at all. Perhaps we should just re-use the existing command server
code in OOo, and re-implement the socket protocol in a more modern way,
together with a new client. Don't know enough 'bout the internals to
really judge this.

In any way, I'd be happy already if those Basic scripts could be replace
by something more 21st-century-like.

Ciao
Frank