You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andrea Pescetti <pe...@apache.org> on 2015/10/25 09:10:18 UTC
[DISCUSS] Re: [VOTE] Release 4.1.2-RC3 as OpenOffice 4.1.2
Damjan Jovanovic wrote:
> [-1] Disapprove
That's bad! Let's see if we can manage to explain it and at least get a
0, since I don't see anything really blocking in your reports (I mean,
we do not require that the release has no issues at all, and we agree
that what we are releasing is better than 4.1.1 was).
> The deal breakers:
> 1. The source tarball (tar.bz2 at least) contains main/MacOSXX64Env.Set and
> main/MacOSXX64Env.Set.sh. I don't believe they belong in there (they're not
> in trunk), and if they do, they're missing ASLv2 licenses and cause
> unapproved license errors in the RAT report.
This is true but it is cosmetic, meaning that this is simply a generated
file that was archived by mistake. If you configure the sources, you
will get this or the corresponding file for other platforms. It is not
in our tagged snapshot at
https://svn.apache.org/viewvc/openoffice/branches/AOO410/main/ and while
it would be possible to simply remove it, I still see it as simply
cosmetic (but I'm available to discuss whether we should remove those
files; this affects only the sources, it is a merely cosmetic change
since those files are unused or overwritten during the build, and it has
zero effect on the binaries so we needn't new binaries; and it does not
even require a commit, since it is a problem with assembling the .tar.gz
file).
> 2. The source fails to build on 32 bit Xubuntu 14.04 both on VMs and
> physical hardware (details later).
We officially support Windows, Mac OS X and Linux. In terms of
"baseline", the reference for Linux is, for historical reasons, CentOS 5
(a still maintained, but quite old, version; this means that our
binaries can run on virtually all distributions); build works there.
There are hundreds of other distributions: with the new bugfixes,
OpenOffice will build on recent versions of Fedora and Ubuntu (64-bit).
Xubuntu 32-bit might be one of the platforms where it is fine to
describe how to fix the build (more below).
> Please can we see links to RAT reports, changelog, test results, code
> quality metrics, and other useful info in the emails proposing a release.
Yes, sorry for not providing them. Here we are:
- RAT reports: https://ci.apache.org/builders/openoffice-linux64-rat
- Changelog: we traditionally have not had a CHANGELOG file. This link
provided by Dennis
https://bz.apache.org/ooo/buglist.cgi?bug_status=CONFIRMED&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f1=flagtypes.name&list_id=170870&o1=substring&query_format=advanced&resolution=---&resolution=FIXED&v1=4.1.2_release_blocker%2B
will show you what changed. I'll update our Release Notes, a subpage of
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.2 , with a
more readable version of it.
- Test results and code quality metrics are not something we are
required to provide (and we actually never did). Does this mean they are
not important? No, they are! We may want to make them part of the
process for trunk, where we now have a better situation thanks to your work.
> Neither Google Test nor the unit test changes themselves were backported
> from trunk to 4.1.2, and many old cppunit tests would fail and break
This is known. An important thing to keep in mind is that 4.1.2 is
closer to 4.1.1 than to trunk: we can't backport all the nice things we
have on trunk. In many situations, 4.1.2 is an improvement to 4.1.1, and
also in this respect 4.1.2 is no worse than 4.1.1.
> ================
> Xubuntu 14.04, 32 bit
> ================
> The binary package installs. Java 7 is automatically detected and used.
> The source reproducibly fails to build (on both VMs and physical hardware)
> in main/svl with this error I reported on the dev list months ago
This seems the typical situation where we would add a comment in the
"known issues" section of the Release Notes saying what to expect, and
how to fix it. A similar situation is the Java 8 compatibility when
building the SDK. In both cases we provide something that people can
build on a variety of easily available systems; and we refer to the
Release Notes for less common cases.
> All these fail on trunk as well, and trunk has 15 additional fvt test
> failures and several errors not present in 4.1.2 :-(.
OK, then I recommend that focus in on trunk for tests. We can't backport
everything and we have to live with the fact that 4.1.2 will be exactly
like 4.1.1 in some respect. For sure, it is no worse than 4.1.1.
> Otherwise thank you everyone for this RC, and hopefully the next one will
> be released.
I hope we will not need a next one! I'm available, as said, to discuss
recreating the source archive and removing the two "temporary" files
that were archived and that are not in SVN. I'll open a thread for this
as soon as I have thoroughly checked it.
The rest of your comments can probably be addressed in Release Notes or
(in the case of tests) on trunk since those improvements are out of
scope for 4.1.2. I don't see any of them as regressions or as blocking
4.1.2.
Thank you for a terrific, very detailed, review. Even though we won't be
able to accommodate all of it into 4.1.2, nothing of it will be wasted.
For sure, you provided plenty of good information to add to the Release
Notes, so you get credit for helping me improve the Release Notes too!
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Re: [VOTE] Release 4.1.2-RC3 as OpenOffice 4.1.2
Posted by Marcus <ma...@wtnet.de>.
I don't see the "...Env.Set.sh" file as code file and therefore the
rules don't apply here. But to be super-sure just delete the generated
file(s) from the source tar balls and rebuild only these new.
And +1 for extending the release notes with the other issues that affect
the binaries.
Marcus
Am 10/25/2015 01:12 PM, schrieb Damjan Jovanovic:
> Ok, I am changing my vote to:
> [0] Abstain
>
> See below for details.
>
> On Sun, Oct 25, 2015 at 10:10 AM, Andrea Pescetti<pe...@apache.org>
> wrote:
>
>> Damjan Jovanovic wrote:
>>
>>> [-1] Disapprove
>>>
>>
>> That's bad! Let's see if we can manage to explain it and at least get a 0,
>> since I don't see anything really blocking in your reports (I mean, we do
>> not require that the release has no issues at all, and we agree that what
>> we are releasing is better than 4.1.1 was).
>>
>> The deal breakers:
>>> 1. The source tarball (tar.bz2 at least) contains main/MacOSXX64Env.Set
>>> and
>>> main/MacOSXX64Env.Set.sh. I don't believe they belong in there (they're
>>> not
>>> in trunk), and if they do, they're missing ASLv2 licenses and cause
>>> unapproved license errors in the RAT report.
>>>
>>
>> This is true but it is cosmetic, meaning that this is simply a generated
>> file that was archived by mistake. If you configure the sources, you will
>> get this or the corresponding file for other platforms. It is not in our
>> tagged snapshot at
>> https://svn.apache.org/viewvc/openoffice/branches/AOO410/main/ and while
>> it would be possible to simply remove it, I still see it as simply cosmetic
>> (but I'm available to discuss whether we should remove those files; this
>> affects only the sources, it is a merely cosmetic change since those files
>> are unused or overwritten during the build, and it has zero effect on the
>> binaries so we needn't new binaries; and it does not even require a commit,
>> since it is a problem with assembling the .tar.gz file).
>>
>>
> I suppose since the file is generated, unused, and was present in previous
> releases, it shouldn't stop this release.
>
> Apache release policy may require those files to be removed or copyright
> notices added because "Every source file must contain the appropriate ASF
> License text" (http://www.apache.org/dev/release.html#license) and "Every
> ASF release *must* comply with ASF licensing policy. This requirement is of
> utmost importance and an audit should be performed before any full release
> is created. In particular, every artifact distributed must contain only
> appropriately licensed code" (http://www.apache.org/dev/release.html). But
> since the file is a generated file and not a source file, that may not
> apply?
>
>
>> 2. The source fails to build on 32 bit Xubuntu 14.04 both on VMs and
>>> physical hardware (details later).
>>>
>>
>> We officially support Windows, Mac OS X and Linux. In terms of "baseline",
>> the reference for Linux is, for historical reasons, CentOS 5 (a still
>> maintained, but quite old, version; this means that our binaries can run on
>> virtually all distributions); build works there. There are hundreds of
>> other distributions: with the new bugfixes, OpenOffice will build on recent
>> versions of Fedora and Ubuntu (64-bit). Xubuntu 32-bit might be one of the
>> platforms where it is fine to describe how to fix the build (more below).
>>
>>
> Ok, good that we use CentOS 5 for binaries. My concern is that if it
> doesn't build on 32-bit Xubuntu, it won't build on 32-bit Ubuntu either, as
> they are very similar. But I'll check that at some stage. Since most people
> don't run Linux, and most Linux users won't be building from source, and of
> those building not all will be on 32-bit (X)ubuntu, and we can document the
> workaround, I guess it's ok.
>
> None of the below should stop the release; I was just commenting generally
> and explaining why some tests weren't done.
>
>
>> Please can we see links to RAT reports, changelog, test results, code
>>> quality metrics, and other useful info in the emails proposing a release.
>>>
>>
>> Yes, sorry for not providing them. Here we are:
>> - RAT reports: https://ci.apache.org/builders/openoffice-linux64-rat
>> - Changelog: we traditionally have not had a CHANGELOG file. This link
>> provided by Dennis
>> https://bz.apache.org/ooo/buglist.cgi?bug_status=CONFIRMED&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f1=flagtypes.name&list_id=170870&o1=substring&query_format=advanced&resolution=---&resolution=FIXED&v1=4.1.2_release_blocker%2B
>> will show you what changed. I'll update our Release Notes, a subpage of
>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.2 , with a
>> more readable version of it.
>> - Test results and code quality metrics are not something we are required
>> to provide (and we actually never did). Does this mean they are not
>> important? No, they are! We may want to make them part of the process for
>> trunk, where we now have a better situation thanks to your work.
>>
>> Neither Google Test nor the unit test changes themselves were backported
>>> from trunk to 4.1.2, and many old cppunit tests would fail and break
>>>
>>
>> This is known. An important thing to keep in mind is that 4.1.2 is closer
>> to 4.1.1 than to trunk: we can't backport all the nice things we have on
>> trunk. In many situations, 4.1.2 is an improvement to 4.1.1, and also in
>> this respect 4.1.2 is no worse than 4.1.1.
>>
>> ================
>>> Xubuntu 14.04, 32 bit
>>> ================
>>> The binary package installs. Java 7 is automatically detected and used.
>>> The source reproducibly fails to build (on both VMs and physical hardware)
>>> in main/svl with this error I reported on the dev list months ago
>>>
>>
>> This seems the typical situation where we would add a comment in the
>> "known issues" section of the Release Notes saying what to expect, and how
>> to fix it. A similar situation is the Java 8 compatibility when building
>> the SDK. In both cases we provide something that people can build on a
>> variety of easily available systems; and we refer to the Release Notes for
>> less common cases.
>>
>> All these fail on trunk as well, and trunk has 15 additional fvt test
>>> failures and several errors not present in 4.1.2 :-(.
>>>
>>
>> OK, then I recommend that focus in on trunk for tests. We can't backport
>> everything and we have to live with the fact that 4.1.2 will be exactly
>> like 4.1.1 in some respect. For sure, it is no worse than 4.1.1.
>>
>> Otherwise thank you everyone for this RC, and hopefully the next one will
>>> be released.
>>>
>>
>> I hope we will not need a next one! I'm available, as said, to discuss
>> recreating the source archive and removing the two "temporary" files that
>> were archived and that are not in SVN. I'll open a thread for this as soon
>> as I have thoroughly checked it.
>>
>> The rest of your comments can probably be addressed in Release Notes or
>> (in the case of tests) on trunk since those improvements are out of scope
>> for 4.1.2. I don't see any of them as regressions or as blocking 4.1.2.
>>
>> Thank you for a terrific, very detailed, review. Even though we won't be
>> able to accommodate all of it into 4.1.2, nothing of it will be wasted. For
>> sure, you provided plenty of good information to add to the Release Notes,
>> so you get credit for helping me improve the Release Notes too!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Re: [VOTE] Release 4.1.2-RC3 as OpenOffice 4.1.2
Posted by Kay Schenk <ka...@gmail.com>.
On 10/25/2015 04:24 PM, Andrea Pescetti wrote:
> Damjan Jovanovic wrote:
>> Ok, I am changing my vote to:
>> [0] Abstain
>
> Thanks for your understanding.
>
>> I suppose since the file is generated, unused, and was present in
>> previous
>> releases, it shouldn't stop this release. ...
>> since the file is a generated file and not a source file, that may
>> not
>> apply?
>
> If this had been caught early in the process, we would still have
> fixed in RC3 since it is trivial to do so. At this point, I opened
> an issue
> https://bz.apache.org/ooo/show_bug.cgi?id=126605
> so that we ensure that this doesn't happen again.
>
>> Ok, good that we use CentOS 5 for binaries. My concern is that if it
>> doesn't build on 32-bit Xubuntu, it won't build on 32-bit Ubuntu
>> either, as
>> they are very similar. But I'll check that at some stage. Since
>> most people
>> don't run Linux, and most Linux users won't be building from
>> source, and of
>> those building not all will be on 32-bit (X)ubuntu, and we can
>> document the
>> workaround, I guess it's ok.
>
> Thanks, issue and workaround noted in
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.2+Release+Notes
>
>
> Regards,
> Andrea.
Just a short FYI. I got curious about this especially in light of
the fact that the Linux-32 SNAPSHOT has been non-functioning for
about a month and I hadn't noticed that. I downloaded the tarball
and built on my CentOS 6.7 32 bit setup and all is well. I should
have done this to begin with I guess. :/ The output from the last
good Linux-32 SNAPSHOT build (Sept. 21) can be found at:
https://ci.apache.org/builders/openoffice-linux32-snapshot
--
--------------------------------------------
MzK
“The journey of a thousand miles begins
with a single step.”
--Lao Tzu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Re: [VOTE] Release 4.1.2-RC3 as OpenOffice 4.1.2
Posted by Andrea Pescetti <pe...@apache.org>.
Damjan Jovanovic wrote:
> Ok, I am changing my vote to:
> [0] Abstain
Thanks for your understanding.
> I suppose since the file is generated, unused, and was present in previous
> releases, it shouldn't stop this release. ...
> since the file is a generated file and not a source file, that may not
> apply?
If this had been caught early in the process, we would still have fixed
in RC3 since it is trivial to do so. At this point, I opened an issue
https://bz.apache.org/ooo/show_bug.cgi?id=126605
so that we ensure that this doesn't happen again.
> Ok, good that we use CentOS 5 for binaries. My concern is that if it
> doesn't build on 32-bit Xubuntu, it won't build on 32-bit Ubuntu either, as
> they are very similar. But I'll check that at some stage. Since most people
> don't run Linux, and most Linux users won't be building from source, and of
> those building not all will be on 32-bit (X)ubuntu, and we can document the
> workaround, I guess it's ok.
Thanks, issue and workaround noted in
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.2+Release+Notes
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] Re: [VOTE] Release 4.1.2-RC3 as OpenOffice 4.1.2
Posted by Damjan Jovanovic <da...@apache.org>.
Ok, I am changing my vote to:
[0] Abstain
See below for details.
On Sun, Oct 25, 2015 at 10:10 AM, Andrea Pescetti <pe...@apache.org>
wrote:
> Damjan Jovanovic wrote:
>
>> [-1] Disapprove
>>
>
> That's bad! Let's see if we can manage to explain it and at least get a 0,
> since I don't see anything really blocking in your reports (I mean, we do
> not require that the release has no issues at all, and we agree that what
> we are releasing is better than 4.1.1 was).
>
> The deal breakers:
>> 1. The source tarball (tar.bz2 at least) contains main/MacOSXX64Env.Set
>> and
>> main/MacOSXX64Env.Set.sh. I don't believe they belong in there (they're
>> not
>> in trunk), and if they do, they're missing ASLv2 licenses and cause
>> unapproved license errors in the RAT report.
>>
>
> This is true but it is cosmetic, meaning that this is simply a generated
> file that was archived by mistake. If you configure the sources, you will
> get this or the corresponding file for other platforms. It is not in our
> tagged snapshot at
> https://svn.apache.org/viewvc/openoffice/branches/AOO410/main/ and while
> it would be possible to simply remove it, I still see it as simply cosmetic
> (but I'm available to discuss whether we should remove those files; this
> affects only the sources, it is a merely cosmetic change since those files
> are unused or overwritten during the build, and it has zero effect on the
> binaries so we needn't new binaries; and it does not even require a commit,
> since it is a problem with assembling the .tar.gz file).
>
>
I suppose since the file is generated, unused, and was present in previous
releases, it shouldn't stop this release.
Apache release policy may require those files to be removed or copyright
notices added because "Every source file must contain the appropriate ASF
License text" (http://www.apache.org/dev/release.html#license) and "Every
ASF release *must* comply with ASF licensing policy. This requirement is of
utmost importance and an audit should be performed before any full release
is created. In particular, every artifact distributed must contain only
appropriately licensed code" (http://www.apache.org/dev/release.html). But
since the file is a generated file and not a source file, that may not
apply?
> 2. The source fails to build on 32 bit Xubuntu 14.04 both on VMs and
>> physical hardware (details later).
>>
>
> We officially support Windows, Mac OS X and Linux. In terms of "baseline",
> the reference for Linux is, for historical reasons, CentOS 5 (a still
> maintained, but quite old, version; this means that our binaries can run on
> virtually all distributions); build works there. There are hundreds of
> other distributions: with the new bugfixes, OpenOffice will build on recent
> versions of Fedora and Ubuntu (64-bit). Xubuntu 32-bit might be one of the
> platforms where it is fine to describe how to fix the build (more below).
>
>
Ok, good that we use CentOS 5 for binaries. My concern is that if it
doesn't build on 32-bit Xubuntu, it won't build on 32-bit Ubuntu either, as
they are very similar. But I'll check that at some stage. Since most people
don't run Linux, and most Linux users won't be building from source, and of
those building not all will be on 32-bit (X)ubuntu, and we can document the
workaround, I guess it's ok.
None of the below should stop the release; I was just commenting generally
and explaining why some tests weren't done.
> Please can we see links to RAT reports, changelog, test results, code
>> quality metrics, and other useful info in the emails proposing a release.
>>
>
> Yes, sorry for not providing them. Here we are:
> - RAT reports: https://ci.apache.org/builders/openoffice-linux64-rat
> - Changelog: we traditionally have not had a CHANGELOG file. This link
> provided by Dennis
> https://bz.apache.org/ooo/buglist.cgi?bug_status=CONFIRMED&bug_status=ACCEPTED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f1=flagtypes.name&list_id=170870&o1=substring&query_format=advanced&resolution=---&resolution=FIXED&v1=4.1.2_release_blocker%2B
> will show you what changed. I'll update our Release Notes, a subpage of
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.2 , with a
> more readable version of it.
> - Test results and code quality metrics are not something we are required
> to provide (and we actually never did). Does this mean they are not
> important? No, they are! We may want to make them part of the process for
> trunk, where we now have a better situation thanks to your work.
>
> Neither Google Test nor the unit test changes themselves were backported
>> from trunk to 4.1.2, and many old cppunit tests would fail and break
>>
>
> This is known. An important thing to keep in mind is that 4.1.2 is closer
> to 4.1.1 than to trunk: we can't backport all the nice things we have on
> trunk. In many situations, 4.1.2 is an improvement to 4.1.1, and also in
> this respect 4.1.2 is no worse than 4.1.1.
>
> ================
>> Xubuntu 14.04, 32 bit
>> ================
>> The binary package installs. Java 7 is automatically detected and used.
>> The source reproducibly fails to build (on both VMs and physical hardware)
>> in main/svl with this error I reported on the dev list months ago
>>
>
> This seems the typical situation where we would add a comment in the
> "known issues" section of the Release Notes saying what to expect, and how
> to fix it. A similar situation is the Java 8 compatibility when building
> the SDK. In both cases we provide something that people can build on a
> variety of easily available systems; and we refer to the Release Notes for
> less common cases.
>
> All these fail on trunk as well, and trunk has 15 additional fvt test
>> failures and several errors not present in 4.1.2 :-(.
>>
>
> OK, then I recommend that focus in on trunk for tests. We can't backport
> everything and we have to live with the fact that 4.1.2 will be exactly
> like 4.1.1 in some respect. For sure, it is no worse than 4.1.1.
>
> Otherwise thank you everyone for this RC, and hopefully the next one will
>> be released.
>>
>
> I hope we will not need a next one! I'm available, as said, to discuss
> recreating the source archive and removing the two "temporary" files that
> were archived and that are not in SVN. I'll open a thread for this as soon
> as I have thoroughly checked it.
>
> The rest of your comments can probably be addressed in Release Notes or
> (in the case of tests) on trunk since those improvements are out of scope
> for 4.1.2. I don't see any of them as regressions or as blocking 4.1.2.
>
> Thank you for a terrific, very detailed, review. Even though we won't be
> able to accommodate all of it into 4.1.2, nothing of it will be wasted. For
> sure, you provided plenty of good information to add to the Release Notes,
> so you get credit for helping me improve the Release Notes too!
>
>
> Regards,
> Andrea.
>
Regards
Damjan