You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Jürgen Schmidt <jo...@googlemail.com> on 2012/03/08 10:50:41 UTC
Request for an early review of an potential Apache OpenOffice release
Hi,
the Apache OpenOffice podling project is moving forward to a first
release that is long expected by the OpenOffice.org community and users.
You know that Apache OpenOffice is the continuation of OpenOffice.org
and that the project is very huge, has a very long history and a very
huge user base all over the world.
IP clearance work to conform to Apache standards" or "to conform to the
Apache Way and we would like to get some early feedback if we are in
shape with the Apache guidelines for a potential release.
We have prepared developer snapshots over the past several weeks for our
project members to test and review. This developer snapshots can be
found under
Source package
http://people.apache.org/~jsc/developer-snapshots/src_releases/srcrelease.html
Binary package
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots
The mac version is also signed and the check files can be found in the
download directory directly
http://people.apache.org/~jsc/developer-snapshots/macos/r1296433/
NOTE: Be careful with the binary packages and save your office user
profiles before testing. Existing OOo 3.x installations will be
overwritten. We provide full install sets to test system integration and
upgrades. Currently we are not able to migrate installed extensions. And
there won't be bundled dictionaries but you can download a dictionary
from the migrated extensions repository
(http://aoo-extensions.sourceforge.net/). But of course we are working
on this.
Please rename your user profile before testing our snapshot build, and
re-rename your user profile after reinstalling a stable OOo version.
Right now we are focusing on show stopper issues but nevertheless we
would like to invite you to review the source packages and also the
binary packages if they fulfill the Apache requirements (e.g license,
NOTICE, ...)
We know that we have no release candidate (RC) right now and that it
would require some work by you. But because of the complexity of the
project we would very much appreciate any kind of early feedback at this
time. And the main goal is to fix potential issues early and to save
time later on when we have a first RC in place.
On behalf of the Apache OpenOffice PPMC
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, Mar 19, 2012 at 5:48 AM, Herbert Duerr <hd...@apache.org> wrote:
> Indeed, thanks. I added the Incubation Disclaimer to the README file.
Great, thanks!
> When even OpenOffice gets abbreviated for the download archives, must they
> all really include the full word "incubation" or only the source archive?
>
> E.g. the install set for version 3.4.0 of the US-English Intel/AMD 64bit
> Linux port already has the quite long name
> OOo_3.4.0_Linux_x86-64-install-arc_en-US.tar.gz
> Should the proper download name be
> Apache_OpenOffice_incubating_3.4.0_Linux_x86-64-install-arc_en-US.tar.gz
> or would
> AOOi_3.4.0_Linux_x86-64-install-arc_en-US.tar.gz
> suffice?
Both of those are unwieldy!
Long-standing Incubator policy is that "incubating" must be in the name:
http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
Should the Incubator PMC, in accordance with these guidelines vote to
approve the request, the Podling MAY perform the release under the following
constraints:
* the release archive MUST contain the word "incubating" in the filename;
and
* the release archive MUST contain an Incubation disclaimer (as described
in the previous section), clearly visible in the main documentation or
README file.
Since shortening doesn't materially change ease of typability or clickability,
I don't see a reason to start down the difficult path of changing that policy
or obtaining a variance.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice
release
Posted by Herbert Duerr <hd...@apache.org>.
> I don't see the Incubation disclaimer in either a dedicated DISCLAIMER file or
> the README. Also, the word "incubating" is not in the archive filename.
Indeed, thanks. I added the Incubation Disclaimer to the README file.
When even OpenOffice gets abbreviated for the download archives, must
they all really include the full word "incubation" or only the source
archive?
E.g. the install set for version 3.4.0 of the US-English Intel/AMD 64bit
Linux port already has the quite long name
OOo_3.4.0_Linux_x86-64-install-arc_en-US.tar.gz
Should the proper download name be
Apache_OpenOffice_incubating_3.4.0_Linux_x86-64-install-arc_en-US.tar.gz
or would
AOOi_3.4.0_Linux_x86-64-install-arc_en-US.tar.gz
suffice?
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice
release
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Marvin Humphrey wrote on Mon, Mar 19, 2012 at 12:24:36 -0700:
> 2012/3/19 Jürgen Schmidt <jo...@googlemail.com>:
>
> >> FWIW, there seemed to be extraneous .txt extensions attached to aoo.KEYS
> >> and some of the checksum files,
> >
> > I am not sure if I understand you here, can you explain it?
>
> Apologies, I have tracked down the root of the problem and it was an error on
> my part when downloading some files via Safari. I have now doublechecked and
> all of the files within this directory have the correct names:
>
> http://people.apache.org/~jsc/developer-snapshots/src_releases/
>
> >> and the format of the checksum files will not work with "md5sum --check"
> >> and "shasum --check" -- but that's all nitpicking.
> >
> > I used gpg on my Mac to generate md5 and sha checksums as found in the docu
> > (). I have to check it but is there an incompatibility already known?
> >
> > Using "md5" on my Mac gave me the same checksum
>
> ... and so long as the sums are the same, that addresses all important
> concerns. :)
>
+1
> FWIW, some people like to use the "md5sum" and "shasum" command line apps
> (which seem to be distributed with certain Linux distros) when validating
> checksums. Output from GPG isn't compatible with those apps, so those users
> must fall back to eyeball comparision. It's a nice convenience to those users
> to put sums in a format that their automatic validation can chew -- but
> speaking from experience it's also a bit of a PITA to do it on a Mac[1].
% sha1sum /dev/null
da39a3ee5e6b4b0d3255bfef95601890afd80709 /dev/null
% sha1 -r /dev/null
da39a3ee5e6b4b0d3255bfef95601890afd80709 /dev/null
% openssl sha1 /dev/null
SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709
% sha1 /dev/null
SHA1 (/dev/null) = da39a3ee5e6b4b0d3255bfef95601890afd80709
% gpg --print-md sha1 /dev/null
/dev/null: DA39 A3EE 5E6B 4B0D 3255 BFEF 9560 1890 AFD8 0709
FWIW, at Subversion the .sha1 files contain just the bare sha1.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Marvin Humphrey <ma...@rectangular.com>.
2012/3/19 Jürgen Schmidt <jo...@googlemail.com>:
>> FWIW, there seemed to be extraneous .txt extensions attached to aoo.KEYS
>> and some of the checksum files,
>
> I am not sure if I understand you here, can you explain it?
Apologies, I have tracked down the root of the problem and it was an error on
my part when downloading some files via Safari. I have now doublechecked and
all of the files within this directory have the correct names:
http://people.apache.org/~jsc/developer-snapshots/src_releases/
>> and the format of the checksum files will not work with "md5sum --check"
>> and "shasum --check" -- but that's all nitpicking.
>
> I used gpg on my Mac to generate md5 and sha checksums as found in the docu
> (). I have to check it but is there an incompatibility already known?
>
> Using "md5" on my Mac gave me the same checksum
... and so long as the sums are the same, that addresses all important
concerns. :)
FWIW, some people like to use the "md5sum" and "shasum" command line apps
(which seem to be distributed with certain Linux distros) when validating
checksums. Output from GPG isn't compatible with those apps, so those users
must fall back to eyeball comparision. It's a nice convenience to those users
to put sums in a format that their automatic validation can chew -- but
speaking from experience it's also a bit of a PITA to do it on a Mac[1].
>> The README starts with a UTF-8-encoded BOM. Just FYI.
>>
> do you see a problem with that?
It was visible in my editor (MacVim), and it's unusual. Prior to reporting it
to you, I checked out Wikipedia:
http://en.wikipedia.org/wiki/UTF-8#Byte_order_mark
The Unicode standard recommends against the BOM for UTF-8.
However, that passage in Wikipedia turns out to be incorrect. :) Here's the
actual text in the Unicode standard (version 6.0 section 2.6), which does not
seem to have changed substantially going back to at least Unicode 4.0:
http://www.unicode.org/versions/Unicode6.0.0/ch02.pdf
Use of a BOM is neither required nor recommended for UTF-8, but may be
encountered in contexts where UTF-8 data is converted from other encoding
forms that use a BOM or where the BOM is used as a UTF-8 signature.
So, since the AOO README is not a source code file, I can only say it was
unusual.
I still favor stripping it because doing so won't hurt anything, and its
presence may confuse machine readers that are not prepared for it -- but it's
not a big deal, I'm just trying to help out with some light QC.
>> I don't see the Incubation disclaimer in either a dedicated DISCLAIMER file
>> or the README. Also, the word "incubating" is not in the archive filename.
>
> I will add it to the README.
>
> Ok we have to add "incubating" to the archive file names.
Sounds good. Those have traditionally been blocking concerns.
Cheers,
Marvin Humphrey
[1] Compatible checksum files can be hand-rolled using Perl and the Digest
module: <http://s.apache.org/UCV>.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice
release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Hi Marvin,
On 3/15/12 4:23 AM, Marvin Humphrey wrote:
> 2012/3/13 Jürgen Schmidt<jo...@googlemail.com>:
>> we have prepared a new developer snapshot on the way to our first release.
>
> Congratulations on your progress so far!
>
>> We would very much appreciate some early feedback if possible.
>
> I can do a little bit of surface level checking. Ordinarily, I would probe
> deeper into source code provenance, but in this case I will have to trust the
> AOO PPMC and the AOO Mentors that proper diligence has been exercised.
>
> The PGP signature and the checksums on the tar.gz archive all looked good.
> FWIW, there seemed to be extraneous .txt extensions attached to aoo.KEYS and
> some of the checksum files,
I am not sure if I understand you here, can you explain it?
and the format of the checksum files will not work
> with "md5sum --check" and "shasum --check" -- but that's all nitpicking.
I used gpg on my Mac to generate md5 and sha checksums as found in the
docu (). I have to check it but is there an incompatibility already known?
Using "md5" on my Mac gave me the same checksum
>
> I was a little surprised that the LICENSE file contained only the ALv2, and
> that NOTICE points at the websites for dependencies and their licensing.
> Ordinarily, I would expect to see entire verbatim licenses for all bundled
> dependencies in LICENSE.
>
> The README starts with a UTF-8-encoded BOM. Just FYI.
>
do you see a problem with that?
> I don't see the Incubation disclaimer in either a dedicated DISCLAIMER file or
> the README. Also, the word "incubating" is not in the archive filename.
I will add it to the README.
Ok we have to add "incubating" to the archive file names.
Thanks for your feedback
Juergen
>
> Hope this helps as a start at least,
>
> Marvin Humphrey
>
> marvin@smokey:~/Desktop $ gpg --verify aoo-3.4-src.tar.gz.asc
> gpg: Signature made Tue Mar 13 00:52:11 2012 PDT using RSA key ID 51B5FDE8
> gpg: Good signature from "Juergen Schnmidt<js...@apache.org>"
> gpg: aka "Juergen Schmidt<jo...@googlemail.com>"
> gpg: aka "Juergen Schmidt<jo...@gmail.com>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the owner.
> Primary key fingerprint: D09F B15F 1A24 768D DF1F A29C CFEE F316 51B5 FDE8
> marvin@smokey:~/Desktop $ gpg --print-md MD5 aoo-3.4-src.tar.gz
> aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2 54 DC 6C E2 3C 32 5F 17
> marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.md5.txt
> aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2 54 DC 6C E2 3C 32 5F 17
> marvin@smokey:~/Desktop $ gpg --print-md SHA1 aoo-3.4-src.tar.gz
> aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468 24CC D245 2DEB 9171 6689
> marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha1.txt
> aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468 24CC D245 2DEB 9171 6689
> marvin@smokey:~/Desktop $ gpg --print-md SHA512 aoo-3.4-src.tar.gz
> aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
> CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
> C62161B5 F16FE64B 5CD144FF ED043D33
> marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha512
> aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
> CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
> C62161B5 F16FE64B 5CD144FF ED043D33
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Rob Weir <ro...@apache.org>.
On Wed, Mar 14, 2012 at 11:23 PM, Marvin Humphrey
<ma...@rectangular.com> wrote:
> 2012/3/13 Jürgen Schmidt <jo...@googlemail.com>:
>> we have prepared a new developer snapshot on the way to our first release.
>
> Congratulations on your progress so far!
>
And thanks for reviewing out dev snapshot build.
>> We would very much appreciate some early feedback if possible.
>
> I can do a little bit of surface level checking. Ordinarily, I would probe
> deeper into source code provenance, but in this case I will have to trust the
> AOO PPMC and the AOO Mentors that proper diligence has been exercised.
>
We've tried to publicly document what we did to clean up the code on our wiki:
https://cwiki.apache.org/confluence/display/OOOUSERS/IP_Clearance
By "clean up" we mean that OpenOffice.org consisted of code that we
received under SGA, but it also had some dependencies on 3rd party
open source libraries. We've gone through each one, and removed the
ones that had incompatible licenses. In almost every case we were
fortunate to find a good substitute with a compatible license.
> The PGP signature and the checksums on the tar.gz archive all looked good.
> FWIW, there seemed to be extraneous .txt extensions attached to aoo.KEYS and
> some of the checksum files, and the format of the checksum files will not work
> with "md5sum --check" and "shasum --check" -- but that's all nitpicking.
>
Good to know.
> I was a little surprised that the LICENSE file contained only the ALv2, and
> that NOTICE points at the websites for dependencies and their licensing.
> Ordinarily, I would expect to see entire verbatim licenses for all bundled
> dependencies in LICENSE.
>
OK.
> The README starts with a UTF-8-encoded BOM. Just FYI.
>
> I don't see the Incubation disclaimer in either a dedicated DISCLAIMER file or
> the README. Also, the word "incubating" is not in the archive filename.
>
OK.
> Hope this helps as a start at least,
>
Yes, thanks.
-Rob
> Marvin Humphrey
>
> marvin@smokey:~/Desktop $ gpg --verify aoo-3.4-src.tar.gz.asc
> gpg: Signature made Tue Mar 13 00:52:11 2012 PDT using RSA key ID 51B5FDE8
> gpg: Good signature from "Juergen Schnmidt <js...@apache.org>"
> gpg: aka "Juergen Schmidt <jo...@googlemail.com>"
> gpg: aka "Juergen Schmidt <jo...@gmail.com>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg: There is no indication that the signature belongs to the owner.
> Primary key fingerprint: D09F B15F 1A24 768D DF1F A29C CFEE F316 51B5 FDE8
> marvin@smokey:~/Desktop $ gpg --print-md MD5 aoo-3.4-src.tar.gz
> aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2 54 DC 6C E2 3C 32 5F 17
> marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.md5.txt
> aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2 54 DC 6C E2 3C 32 5F 17
> marvin@smokey:~/Desktop $ gpg --print-md SHA1 aoo-3.4-src.tar.gz
> aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468 24CC D245 2DEB 9171 6689
> marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha1.txt
> aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468 24CC D245 2DEB 9171 6689
> marvin@smokey:~/Desktop $ gpg --print-md SHA512 aoo-3.4-src.tar.gz
> aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
> CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
> C62161B5 F16FE64B 5CD144FF ED043D33
> marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha512
> aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
> CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
> C62161B5 F16FE64B 5CD144FF ED043D33
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Marvin Humphrey <ma...@rectangular.com>.
2012/3/13 Jürgen Schmidt <jo...@googlemail.com>:
> we have prepared a new developer snapshot on the way to our first release.
Congratulations on your progress so far!
> We would very much appreciate some early feedback if possible.
I can do a little bit of surface level checking. Ordinarily, I would probe
deeper into source code provenance, but in this case I will have to trust the
AOO PPMC and the AOO Mentors that proper diligence has been exercised.
The PGP signature and the checksums on the tar.gz archive all looked good.
FWIW, there seemed to be extraneous .txt extensions attached to aoo.KEYS and
some of the checksum files, and the format of the checksum files will not work
with "md5sum --check" and "shasum --check" -- but that's all nitpicking.
I was a little surprised that the LICENSE file contained only the ALv2, and
that NOTICE points at the websites for dependencies and their licensing.
Ordinarily, I would expect to see entire verbatim licenses for all bundled
dependencies in LICENSE.
The README starts with a UTF-8-encoded BOM. Just FYI.
I don't see the Incubation disclaimer in either a dedicated DISCLAIMER file or
the README. Also, the word "incubating" is not in the archive filename.
Hope this helps as a start at least,
Marvin Humphrey
marvin@smokey:~/Desktop $ gpg --verify aoo-3.4-src.tar.gz.asc
gpg: Signature made Tue Mar 13 00:52:11 2012 PDT using RSA key ID 51B5FDE8
gpg: Good signature from "Juergen Schnmidt <js...@apache.org>"
gpg: aka "Juergen Schmidt <jo...@googlemail.com>"
gpg: aka "Juergen Schmidt <jo...@gmail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: D09F B15F 1A24 768D DF1F A29C CFEE F316 51B5 FDE8
marvin@smokey:~/Desktop $ gpg --print-md MD5 aoo-3.4-src.tar.gz
aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2 54 DC 6C E2 3C 32 5F 17
marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.md5.txt
aoo-3.4-src.tar.gz: 9B 5B 55 09 68 DE 7A C2 54 DC 6C E2 3C 32 5F 17
marvin@smokey:~/Desktop $ gpg --print-md SHA1 aoo-3.4-src.tar.gz
aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468 24CC D245 2DEB 9171 6689
marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha1.txt
aoo-3.4-src.tar.gz: 83B7 F124 F967 4D5E 3468 24CC D245 2DEB 9171 6689
marvin@smokey:~/Desktop $ gpg --print-md SHA512 aoo-3.4-src.tar.gz
aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
C62161B5 F16FE64B 5CD144FF ED043D33
marvin@smokey:~/Desktop $ cat aoo-3.4-src.tar.gz.sha512
aoo-3.4-src.tar.gz: 3898D4EC 92917120 87A016F8 075E3B7B B87E44B0 FED22E3B
CF5D8850 90CA2713 E9F98A6E 51522AEF 50DC6F30 F36860C4
C62161B5 F16FE64B 5CD144FF ED043D33
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice
release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/28/12 9:22 PM, Marvin Humphrey wrote:
> 2012/3/28 Jürgen Schmidt<jo...@googlemail.com>:
>> On 3/28/12 12:46 AM, Marvin Humphrey wrote:
>
>>>> It is more or less a pure svn dump.
>>>
>>> Right -- just with a few files moved around and a bunch filtered out.
>>
>> yes, we build the src release package as part of a normal build and I
>> exclude all svn fiels + generated files during the build.
>
> FWIW, I like to start from an "svn export" of the release candidate tag so
> that there's no need to exclude version control files.
>
>>> Are you confident that all the files which match those wildcards were part
>>> of the Oracle SGA or are otherwise properly licensed for ASF usage?
>>
>> yes I think so, the rat exclude list is maintained mainly from somebody who
>> should know what's part of the SGA
>
> OK, good enough. I'm not going to perform a low-level audit. For this
> release, I trust the IP clearance process and the Mentors who supervised it.
> For future releases, the IP integrity of this codebase will be the ongoing
> responsibility of the AOO development community, and from what I can tell you
> folks have the expertise, the incentives, the desire and the habits to serve
> as good stewards.
>
> In my view, the process by which this prelimary release candidate was
> assembled was satisfactory. Once the RAT report passes and once the
> LICENSE/NOTICE files have been worked out according to the plan proposed by
> Oliver-Rainer Wittmann on legal-discuss, I expect to vote +1 on a true AOO
> release candidate unless someone else catches something I missed.
We will definitely work on the RAT exclude file to split the wildcards
into smaller pieces with descriptions why these files are excluded. We
have simply so many files and as long as they are covered by the SGA we
thought we can start with this simplified approach. Much more work in
other real code areas was to do as well.
On the other hand I think it is very important that we bring a first
release on the road to show that the project exists and is living.
But overall I think we are on a good way.
Juergen
>
> Cheers,
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Marvin Humphrey <ma...@rectangular.com>.
2012/3/28 Jürgen Schmidt <jo...@googlemail.com>:
> On 3/28/12 12:46 AM, Marvin Humphrey wrote:
>>> It is more or less a pure svn dump.
>>
>> Right -- just with a few files moved around and a bunch filtered out.
>
> yes, we build the src release package as part of a normal build and I
> exclude all svn fiels + generated files during the build.
FWIW, I like to start from an "svn export" of the release candidate tag so
that there's no need to exclude version control files.
>> Are you confident that all the files which match those wildcards were part
>> of the Oracle SGA or are otherwise properly licensed for ASF usage?
>
> yes I think so, the rat exclude list is maintained mainly from somebody who
> should know what's part of the SGA
OK, good enough. I'm not going to perform a low-level audit. For this
release, I trust the IP clearance process and the Mentors who supervised it.
For future releases, the IP integrity of this codebase will be the ongoing
responsibility of the AOO development community, and from what I can tell you
folks have the expertise, the incentives, the desire and the habits to serve
as good stewards.
In my view, the process by which this prelimary release candidate was
assembled was satisfactory. Once the RAT report passes and once the
LICENSE/NOTICE files have been worked out according to the plan proposed by
Oliver-Rainer Wittmann on legal-discuss, I expect to vote +1 on a true AOO
release candidate unless someone else catches something I missed.
Cheers,
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice
release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/28/12 12:46 AM, Marvin Humphrey wrote:
> 2012/3/26 Jürgen Schmidt<jo...@googlemail.com>:
>> I created and used an ant script (main/solenv/bin/srcrelease.xml) to create
>> the src release files as part of the normal build if required. I decided to
>> use ant because it allows me some flexibility...
>>
>> Our trunk contains 4 directories where trunk/ext_sources shouldn't be
>> included in a src release because it contains external library packages for
>> convenient purposes only. We have to patch some external libs for example
>> where an upstreaming is not possible or where the versions we use are too
>> old. That is something we would like to improve in the future and over time.
>> But they will be downloaded on demand.
>
> OK, I think that sounds right.
>
>> trunk/main
>> trunk/ext_libraries
>> trunk/ext_sources
>> trunk/extras
>>
>> That means I include main, ext_libraries and extras only. ext_libraries is a
>> new module where we started to collect build projects for external libs in
>> our own office specific build env etc. Main purpose is to have a cleaner
>> separation over time.
>>
>> trunk/main/NOTICE and trunk/main/LICENSE and trunk/main/README are moved in
>> the destination root directory of our src release to simply have it in the
>> root as expected.
>>
>> We kept trunk clean so far or better we don't put any files in trunk
>> directly and used main as the main source directory. extras contains
>> translation files only to keep them somewhat separated as well.
>
> I had a brief glance at srcrelease.xml, and between that and your description
> of how the system has been set up, I'm content that you understand the
> requirements and are making a good-faith effort to uphold them.
>
>>> Canonical ASF source releases are supposed to be assembled using a
>>> repeatable build process.
>>
>>
>> I think it is very repeatable and the script used is part of the source as
>> well.
>
> Excellent.
>
>> see my description above, anybody can build the src release no local setup
>> necessary.
>>
>> It is more or less a pure svn dump.
>
> Right -- just with a few files moved around and a bunch filtered out.
yes, we build the src release package as part of a normal build and I
exclude all svn fiels + generated files during the build.
>
>> We run RAT on our build bots (at least on one) and use the exclude list that
>> you can find in trunk/main/rat-excludes
>>
>> You can find the nightly output under
>> http://ci.apache.org/projects/openoffice/rat-output.html
>>
>> Right now we have still 1471 files with unknown license but they are more or
>> less all part of the SGA or should be.
>>
>> We are working right now on these files and analyze if it's possible to
>> include a license header or not. OR put in in the exclude file with a proper
>> comment to document everything.
>
> Nice workflow, +1.
>
> I had a look at the rat-excludes file. The individual files which are listed
> and documented in the lower half -- that all looks great.
>
> The top half, though, has an awful lot of wildcards:
>
> **/*.add
> **/*.all
> **/*.am
> **/*.applications
> **/*.attr
> **/*.btm
> **/*.cgm
> **/*.chd
> **/*.cl
> **/*.cls
> **/*.cmn
> **/*.common
> **/*.component
> **/*.components
> [...]
>
> # binary media formats
> **/*.bmp
> **/*.emf
> **/*.eps
> **/*.gif
> **/*.giff
> **/*.icns
> **/*.ico
> **/*.img
> **/*.jpeg
> **/*.jpg
> **/*.mov
> [...]
>
> # binary document formats
> **/*.doc
> **/*.docx
> **/*.odb
> **/*.odf
> **/*.odg
> **/*.odl
> [...]
>
> I understand that a lot of those filetypes can't have embedded licenses.
> Ideally, each such file would be listed together with a comment explaining its
> licensing situation. Less desirable but still acceptable to list wildcards
> within directories, explaining where e.g. all the images in
> this/folder/full/of/*.jpeg files came from. Having wildcards which exclude a
> file type for the whole source tree, though, weakens the RAT check, both now
> and in the future.
>
> Are you confident that all the files which match those wildcards were part of
> the Oracle SGA or are otherwise properly licensed for ASF usage?
yes I think so, the rat exclude list is maintained mainly from somebody
who should know what's part of the SGA
Juergen
>
> Thanks,
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Marvin Humphrey <ma...@rectangular.com>.
2012/3/26 Jürgen Schmidt <jo...@googlemail.com>:
> I created and used an ant script (main/solenv/bin/srcrelease.xml) to create
> the src release files as part of the normal build if required. I decided to
> use ant because it allows me some flexibility...
>
> Our trunk contains 4 directories where trunk/ext_sources shouldn't be
> included in a src release because it contains external library packages for
> convenient purposes only. We have to patch some external libs for example
> where an upstreaming is not possible or where the versions we use are too
> old. That is something we would like to improve in the future and over time.
> But they will be downloaded on demand.
OK, I think that sounds right.
> trunk/main
> trunk/ext_libraries
> trunk/ext_sources
> trunk/extras
>
> That means I include main, ext_libraries and extras only. ext_libraries is a
> new module where we started to collect build projects for external libs in
> our own office specific build env etc. Main purpose is to have a cleaner
> separation over time.
>
> trunk/main/NOTICE and trunk/main/LICENSE and trunk/main/README are moved in
> the destination root directory of our src release to simply have it in the
> root as expected.
>
> We kept trunk clean so far or better we don't put any files in trunk
> directly and used main as the main source directory. extras contains
> translation files only to keep them somewhat separated as well.
I had a brief glance at srcrelease.xml, and between that and your description
of how the system has been set up, I'm content that you understand the
requirements and are making a good-faith effort to uphold them.
>> Canonical ASF source releases are supposed to be assembled using a
>> repeatable build process.
>
>
> I think it is very repeatable and the script used is part of the source as
> well.
Excellent.
> see my description above, anybody can build the src release no local setup
> necessary.
>
> It is more or less a pure svn dump.
Right -- just with a few files moved around and a bunch filtered out.
> We run RAT on our build bots (at least on one) and use the exclude list that
> you can find in trunk/main/rat-excludes
>
> You can find the nightly output under
> http://ci.apache.org/projects/openoffice/rat-output.html
>
> Right now we have still 1471 files with unknown license but they are more or
> less all part of the SGA or should be.
>
> We are working right now on these files and analyze if it's possible to
> include a license header or not. OR put in in the exclude file with a proper
> comment to document everything.
Nice workflow, +1.
I had a look at the rat-excludes file. The individual files which are listed
and documented in the lower half -- that all looks great.
The top half, though, has an awful lot of wildcards:
**/*.add
**/*.all
**/*.am
**/*.applications
**/*.attr
**/*.btm
**/*.cgm
**/*.chd
**/*.cl
**/*.cls
**/*.cmn
**/*.common
**/*.component
**/*.components
[...]
# binary media formats
**/*.bmp
**/*.emf
**/*.eps
**/*.gif
**/*.giff
**/*.icns
**/*.ico
**/*.img
**/*.jpeg
**/*.jpg
**/*.mov
[...]
# binary document formats
**/*.doc
**/*.docx
**/*.odb
**/*.odf
**/*.odg
**/*.odl
[...]
I understand that a lot of those filetypes can't have embedded licenses.
Ideally, each such file would be listed together with a comment explaining its
licensing situation. Less desirable but still acceptable to list wildcards
within directories, explaining where e.g. all the images in
this/folder/full/of/*.jpeg files came from. Having wildcards which exclude a
file type for the whole source tree, though, weakens the RAT check, both now
and in the future.
Are you confident that all the files which match those wildcards were part of
the Oracle SGA or are otherwise properly licensed for ASF usage?
Thanks,
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice
release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 3/24/12 5:28 PM, Marvin Humphrey wrote:
> 2012/3/13 Jürgen Schmidt<jo...@googlemail.com>:
>> we have prepared a new developer snapshot on the way to our first release.
>
> Hello again... I have a couple more questions.
sorry for the late response, I haven't noticed it before
>
> It looks like the dev snapshot src tarball is an export of svn trunk, but with
> LICENSE and NOTICE hoisted out of trunk/main/ into the top level. Is that
> right? If not, can you describe the process by which the src release was
> created?
>
ok, let me explain what I did.
I created and used an ant script (main/solenv/bin/srcrelease.xml) to
create the src release files as part of the normal build if required. I
decided to use ant because it allows me some flexibility...
Our trunk contains 4 directories where trunk/ext_sources shouldn't be
included in a src release because it contains external library packages
for convenient purposes only. We have to patch some external libs for
example where an upstreaming is not possible or where the versions we
use are too old. That is something we would like to improve in the
future and over time. But they will be downloaded on demand.
trunk/main
trunk/ext_libraries
trunk/ext_sources
trunk/extras
That means I include main, ext_libraries and extras only. ext_libraries
is a new module where we started to collect build projects for external
libs in our own office specific build env etc. Main purpose is to have a
cleaner separation over time.
trunk/main/NOTICE and trunk/main/LICENSE and trunk/main/README are moved
in the destination root directory of our src release to simply have it
in the root as expected.
We kept trunk clean so far or better we don't put any files in trunk
directly and used main as the main source directory. extras contains
translation files only to keep them somewhat separated as well.
> Canonical ASF source releases are supposed to be assembled using a repeatable
> build process.
I think it is very repeatable and the script used is part of the source
as well.
You can run it during a normal build
cd main/instsetoo_native/util
dmake aoo_srcrelease
The resulting files can be found in the output directory besides the
normal office builds.
The simple ideal is to capture a bare "svn export" to an
> archive so that the source release matches a tag in version control; many
> projects also capture a handful of generated files (because they use Maven or
> whatever to prepare their releases), but in such cases it must be clear what
> those files are and where they came from, and having a large number of
> generated files is discouraged. What we want to avoid is having a src release
> dependent on the release manager's local setup, in a worst case vacuuming up
> local files which are not present in version control. So... if you could let
> us know how the src archive was created, that would be helpful.
see my description above, anybody can build the src release no local
setup necessary.
It is more or less a pure svn dump.
>
> What would also be helpful is if you could describe how you are using RAT.
> Incubator PMC members typically run raw RAT when vetting releases and review
> any files it flags individually, but that's not realistic for AOO -- I
> just turned RAT loose on the snapshot and it reported "10793 Unknown
> Licenses". :) My local copy of RAT is a little old, but even if I bring it
> up to date I'm sure I'm going to need to use your exclusion lists.
We run RAT on our build bots (at least on one) and use the exclude list
that you can find in trunk/main/rat-excludes
You can find the nightly output under
http://ci.apache.org/projects/openoffice/rat-output.html
Right now we have still 1471 files with unknown license but they are
more or less all part of the SGA or should be.
We are working right now on these files and analyze if it's possible to
include a license header or not. OR put in in the exclude file with a
proper comment to document everything.
>
> Lastly, for the record I tried to build from the source archive on my MacBook
> Pro running Snow Leopard but ran into problems. That would ordinarily be a
> concern for an incubating release, but for AOO I don't think having IPMC
> members run a build-and-test check is particularly useful. Not a blocker.
well this beast of software needs some preparation before. We have
longer list of build requirements document in the wiki. In the end it is
a one time preparation for our volunteers.
I hope we can improve this in the future as well but it's indeed not
comparable with a Java library project. Sometimes I wish I would work on
something smaller without such a long history and old code ;-)
I hope this helps to answer your questions, let me know if you need more
info.
Juergen
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Marvin Humphrey <ma...@rectangular.com>.
2012/3/13 Jürgen Schmidt <jo...@googlemail.com>:
> we have prepared a new developer snapshot on the way to our first release.
Hello again... I have a couple more questions.
It looks like the dev snapshot src tarball is an export of svn trunk, but with
LICENSE and NOTICE hoisted out of trunk/main/ into the top level. Is that
right? If not, can you describe the process by which the src release was
created?
Canonical ASF source releases are supposed to be assembled using a repeatable
build process. The simple ideal is to capture a bare "svn export" to an
archive so that the source release matches a tag in version control; many
projects also capture a handful of generated files (because they use Maven or
whatever to prepare their releases), but in such cases it must be clear what
those files are and where they came from, and having a large number of
generated files is discouraged. What we want to avoid is having a src release
dependent on the release manager's local setup, in a worst case vacuuming up
local files which are not present in version control. So... if you could let
us know how the src archive was created, that would be helpful.
What would also be helpful is if you could describe how you are using RAT.
Incubator PMC members typically run raw RAT when vetting releases and review
any files it flags individually, but that's not realistic for AOO -- I
just turned RAT loose on the snapshot and it reported "10793 Unknown
Licenses". :) My local copy of RAT is a little old, but even if I bring it
up to date I'm sure I'm going to need to use your exclusion lists.
Lastly, for the record I tried to build from the source archive on my MacBook
Pro running Snow Leopard but ran into problems. That would ordinarily be a
concern for an incubating release, but for AOO I don't think having IPMC
members run a build-and-test check is particularly useful. Not a blocker.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Ross Gardler <rg...@opendirective.com>.
Sent from my mobile device, please forgive errors and brevity.
On Mar 15, 2012 1:22 AM, "Jukka Zitting" <ju...@gmail.com> wrote:
>
> Hi,
>
> 2012/3/13 Jürgen Schmidt <jo...@googlemail.com>:
> > We would very much appreciate some early feedback if possible.
>
> OpenOffice mentors, can you take care of this? If not, any volunteers
> from the rest of the IPMC?
Yes, mentors are dealing with it. However this is an extremely large code
base moving from LGPL. More eyes are good and I, as a mentor, felt the IPMC
should be invited to help early in an attempt to avoid multiple rounds of
review/build cycles.
Ross
>
> BR,
>
> Jukka Zitting
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: Request for an early review of an potential Apache OpenOffice release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
2012/3/13 Jürgen Schmidt <jo...@googlemail.com>:
> We would very much appreciate some early feedback if possible.
OpenOffice mentors, can you take care of this? If not, any volunteers
from the rest of the IPMC?
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Request for an early review of an potential Apache OpenOffice
release
Posted by Jürgen Schmidt <jo...@googlemail.com>.
Hi,
we have prepared a new developer snapshot on the way to our first release.
We would very much appreciate some early feedback if possible. The
AOO3.4 release will be an important milestone for the project and I
think also for Apache to show that project is up and running. And that
Apache is able to host and drive the project forward.
Kind regards
Juergen
On 3/8/12 10:50 AM, Jürgen Schmidt wrote:
> Hi,
>
> the Apache OpenOffice podling project is moving forward to a first
> release that is long expected by the OpenOffice.org community and users.
>
> You know that Apache OpenOffice is the continuation of OpenOffice.org
> and that the project is very huge, has a very long history and a very
> huge user base all over the world.
>
> IP clearance work to conform to Apache standards" or "to conform to the
> Apache Way and we would like to get some early feedback if we are in
> shape with the Apache guidelines for a potential release.
>
> We have prepared developer snapshots over the past several weeks for our
> project members to test and review. This developer snapshots can be
> found under
>
> Source package
> http://people.apache.org/~jsc/developer-snapshots/src_releases/srcrelease.html
>
>
> Binary package
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots
>
>
> The mac version is also signed and the check files can be found in the
> download directory directly
> http://people.apache.org/~jsc/developer-snapshots/macos/r1296433/
>
> NOTE: Be careful with the binary packages and save your office user
> profiles before testing. Existing OOo 3.x installations will be
> overwritten. We provide full install sets to test system integration and
> upgrades. Currently we are not able to migrate installed extensions. And
> there won't be bundled dictionaries but you can download a dictionary
> from the migrated extensions repository
> (http://aoo-extensions.sourceforge.net/). But of course we are working
> on this.
>
> Please rename your user profile before testing our snapshot build, and
> re-rename your user profile after reinstalling a stable OOo version.
>
> Right now we are focusing on show stopper issues but nevertheless we
> would like to invite you to review the source packages and also the
> binary packages if they fulfill the Apache requirements (e.g license,
> NOTICE, ...)
>
> We know that we have no release candidate (RC) right now and that it
> would require some work by you. But because of the complexity of the
> project we would very much appreciate any kind of early feedback at this
> time. And the main goal is to fix potential issues early and to save
> time later on when we have a first RC in place.
>
> On behalf of the Apache OpenOffice PPMC
>
> Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org