Re: A systematic approach to IP review?
Hi; Is there an updated SGA already? 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/rat/
RE: A systematic approach to IP review?
+1 -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Sunday, September 18, 2011 17:27 To: ooo-dev@incubator.apache.org Subject: A systematic approach to IP review? 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/rat/
Re: The OOo Community Wiki handover of activities
On 14/09/11 08:40, Terry Ellison wrote: ... So please expect to see a file http://user.services.openoffice.org/__backup/d27f1bb7c71872c4d2e6eb04d4fc6006/README posted next at the weekend which will explain how to download this content... Done. //T
A systematic approach to IP review?
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/rat/
Re: VCL TestTool
Am 18.09.2011 20:41, schrieb Bjoern Michaelsen: > Hi Rob, Hi Mathias, > > On Sun, 18 Sep 2011 13:42:54 -0400 > Rob Weir wrote: > >> Is there a different tool for GUI test automation that we should be >> investing in going forward? > > you might be interested in: > > http://nabble.documentfoundation.org/subsequenttests-now-run-headless-td2750447.html > > for a few additional viewpoints on the test suites. (Not so thrilling > for Mathias I guess, as he knows the arguments and the positions > expressed, but still.) While I agree with your wrt. the subsequenttests, I think that it doesn't address Rob's question. About GUI test automation: If we want to continue GUI automation, IMHO there is no testtool available that could replace the vcl testtool. As not all GUI elements in OOo are native controls, there will always be some parts of OOo that can't be tested with any other available tool. And I doubt that there are any platform independent GUI tools at all that could be a candidate for OOo testing. So we have three options: - do no automated GUI testing at all - try to continue using the existing testtool that exists as a binary and hopefully is still available on some people's hard disk (I have versions for Windows and Linux 32 Bit) - fix the testtool code in the "automation" module and try to create a newer and better version of it. Regards, Mathias
Re: [code][repo] Integration of CWSs, HOW-TO with hg and git svn and stgit
Am 18.09.2011 01:04, schrieb Michael Stahl: > - mba34issues01: somebody said that he would do this one; > Mathias, how long do we have to wait... :) Done. Regards, Mathias
Re: VCL TestTool
Hi Rob, Hi Mathias, On Sun, 18 Sep 2011 13:42:54 -0400 Rob Weir wrote: > Is there a different tool for GUI test automation that we should be > investing in going forward? you might be interested in: http://nabble.documentfoundation.org/subsequenttests-now-run-headless-td2750447.html for a few additional viewpoints on the test suites. (Not so thrilling for Mathias I guess, as he knows the arguments and the positions expressed, but still.) Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen
Re: VCL TestTool
On Sun, Sep 18, 2011 at 1:07 PM, Mathias Bauer wrote:
> Am 18.09.2011 17:34, schrieb Raphael Bircher:
>
>> Hi at all
>>
>> The VCL TestTool is a GUI Testtool for OpenOffice.org who was writen by
>> SUN and wildly used in by the Hamburg people. The VCL TestTool (short
>> TT) is designed to avoid regressions. I the past, the test was not a
>> load used by the community, and same people say, TT is only wasting time
>> that can be better used by manual testing. There are two disavantage
>> with the TT.
>
> The testtool has some value if it is used with careful consideration and
> not as a blind adherence to some stupid rules ("Thou shalt not integrate
> code without running the testtool on it").
>
>> So I will give the TT a chance, and started to testing with it, and I
>> was surprised. The first Test brings a error. Within five minutes I can
>> confirm it manualy. It was the "save with password error". Well, maybe
>> this was also a bit luck, but even it takes 20 Minutes to analyse the
>> error, it's the time wrote.
>
> This backs up my experience with the test tool: it is best used when
> larger parts of the code have been replaced, rewritten or removed. Like
> now. Though you should be prepared for a lot of red herrings, especially
> on Linux (the Windows runs take longer but from my own experience are
> much more reliable).
>
> Using the testtool in the long run is problematic: the developers of
> that tool didn't maintain its source code for years, so nowadays it's
> impossible to create a running testtool from the current sources. OTOH
> the sources of the currently available binary instance of the testtool
> are several years old an sooner or later won't run anymore. The Linux
> version already does not run at least on 64Bit Ubuntu.
>
> The quality of the test scripts also is average at best. And many tests
> are superfluous, some of them are carried out up to 9 times, just
> wasting time.
>
Is there a different tool for GUI test automation that we should be
investing in going forward?
> Regards,
> Mathias
>
Re: [solved] Build braker on Mac OS X
Moin, it seems that configure wasn't updated in the repo and in fact I remember that we agreed that this is the sane approach. So we should make clear in the build instructions that our process has changed: the first thing to do after getting the source or pulling a change of configure.in is calling "autoconf", not calling "configure". IMHO we also should remove "configure" from the repository so that it is no longer tracked. Regards, Mathias Am 18.09.2011 09:35, schrieb Raphael Bircher: > Hi all. > > Pavel help me to solve the issue. We have to re run autoconf. I will > commit the new configure > > Greetings Raphael > > Am 18.09.11 09:01, schrieb Raphael Bircher: >> Hi at all >> >> since the last CWS integration from Michael Stahl, I have a build >> braker on my mac. Normaly I succsfully build on this mashine. It fails >> at the ./configure process >> >> My configure settings: >> ./configure --disable-odk --disable-pasf --disable-gtk >> --disable-headless --disable-build-mozilla >> --with-build-version=$OOVERSION-`date +%d-%m-%y` --disable-fontconfig >> --without-nas >> --with-jdk-home=/System/Library/Frameworks/JavaVM.framework/Home >> --with-stlport=no --disable-mediawiki --enable-werror --disable-vba >> --with-num-cpus=2 --with-max-jobs=2 --disable-copyleft >> >> The error message: >> Possible unintended interpolation of @ENABLE_CAIRO_CANVAS in string at >> ./set_soenv line 1638. >> Global symbol "@ENABLE_CAIRO_CANVAS" requires explicit package name at >> ./set_soenv line 1638. >> Execution of ./set_soenv aborted due to compilation errors. >> server3:main server3$ echo $ENABLE_CAIRO_CANVAS >> >> Looks like samething with env Variables is wrong. >> >> Greetings Raphael > >
Re: VCL TestTool
Am 18.09.2011 17:34, schrieb Raphael Bircher:
> Hi at all
>
> The VCL TestTool is a GUI Testtool for OpenOffice.org who was writen by
> SUN and wildly used in by the Hamburg people. The VCL TestTool (short
> TT) is designed to avoid regressions. I the past, the test was not a
> load used by the community, and same people say, TT is only wasting time
> that can be better used by manual testing. There are two disavantage
> with the TT.
The testtool has some value if it is used with careful consideration and
not as a blind adherence to some stupid rules ("Thou shalt not integrate
code without running the testtool on it").
> So I will give the TT a chance, and started to testing with it, and I
> was surprised. The first Test brings a error. Within five minutes I can
> confirm it manualy. It was the "save with password error". Well, maybe
> this was also a bit luck, but even it takes 20 Minutes to analyse the
> error, it's the time wrote.
This backs up my experience with the test tool: it is best used when
larger parts of the code have been replaced, rewritten or removed. Like
now. Though you should be prepared for a lot of red herrings, especially
on Linux (the Windows runs take longer but from my own experience are
much more reliable).
Using the testtool in the long run is problematic: the developers of
that tool didn't maintain its source code for years, so nowadays it's
impossible to create a running testtool from the current sources. OTOH
the sources of the currently available binary instance of the testtool
are several years old an sooner or later won't run anymore. The Linux
version already does not run at least on 64Bit Ubuntu.
The quality of the test scripts also is average at best. And many tests
are superfluous, some of them are carried out up to 9 times, just
wasting time.
Regards,
Mathias
VCL TestTool
Hi at all The VCL TestTool is a GUI Testtool for OpenOffice.org who was writen by SUN and wildly used in by the Hamburg people. The VCL TestTool (short TT) is designed to avoid regressions. I the past, the test was not a load used by the community, and same people say, TT is only wasting time that can be better used by manual testing. There are two disavantage with the TT. 1) The TT runs with testscripts wich are writen in a basic dialect. If we want to use TT we have to maintain this testscripts. 2) TT is a realy sensitiv. Sametimes TT see a error wich you can't find with manual testing. So in fact, TT see same errors who won't exist. But ther also avantages by this tool: 1) The TT is faster as a User 2) SUN/Oracle spend a load of Time in writing testscripts. We have about two days (48 h) tests. We will never have so many testers to do the same with manual testing. TT don't replace manual testing, but can be a great support to avoid regressions. the condition is, that the TT works proper. So I will give the TT a chance, and started to testing with it, and I was surprised. The first Test brings a error. Within five minutes I can confirm it manualy. It was the "save with password error". Well, maybe this was also a bit luck, but even it takes 20 Minutes to analyse the error, it's the time wrote. I will run now all the scripts one time with a AOOo means builded with --disable-copyleft. Then makes a list with the problem area we have. I like also to see, how many wrong errors that TT will found. I will upload the .res file to my apache Account, so everyone can see it. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Re: [solved] Build braker on Mac OS X
Hi all. Pavel help me to solve the issue. We have to re run autoconf. I will commit the new configure Greetings Raphael Am 18.09.11 09:01, schrieb Raphael Bircher: Hi at all since the last CWS integration from Michael Stahl, I have a build braker on my mac. Normaly I succsfully build on this mashine. It fails at the ./configure process My configure settings: ./configure --disable-odk --disable-pasf --disable-gtk --disable-headless --disable-build-mozilla --with-build-version=$OOVERSION-`date +%d-%m-%y` --disable-fontconfig --without-nas --with-jdk-home=/System/Library/Frameworks/JavaVM.framework/Home --with-stlport=no --disable-mediawiki --enable-werror --disable-vba --with-num-cpus=2 --with-max-jobs=2 --disable-copyleft The error message: Possible unintended interpolation of @ENABLE_CAIRO_CANVAS in string at ./set_soenv line 1638. Global symbol "@ENABLE_CAIRO_CANVAS" requires explicit package name at ./set_soenv line 1638. Execution of ./set_soenv aborted due to compilation errors. server3:main server3$ echo $ENABLE_CAIRO_CANVAS Looks like samething with env Variables is wrong. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
Build braker on Mac OS X
Hi at all since the last CWS integration from Michael Stahl, I have a build braker on my mac. Normaly I succsfully build on this mashine. It fails at the ./configure process My configure settings: ./configure --disable-odk --disable-pasf --disable-gtk --disable-headless --disable-build-mozilla --with-build-version=$OOVERSION-`date +%d-%m-%y` --disable-fontconfig --without-nas --with-jdk-home=/System/Library/Frameworks/JavaVM.framework/Home --with-stlport=no --disable-mediawiki --enable-werror --disable-vba --with-num-cpus=2 --with-max-jobs=2 --disable-copyleft The error message: Possible unintended interpolation of @ENABLE_CAIRO_CANVAS in string at ./set_soenv line 1638. Global symbol "@ENABLE_CAIRO_CANVAS" requires explicit package name at ./set_soenv line 1638. Execution of ./set_soenv aborted due to compilation errors. server3:main server3$ echo $ENABLE_CAIRO_CANVAS Looks like samething with env Variables is wrong. Greetings Raphael -- My private Homepage: http://www.raphaelbircher.ch/
