openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <>
Subject [DISCUSS] Re: [VOTE] Release 4.1.2-RC3 as OpenOffice 4.1.2
Date Sun, 25 Oct 2015 08:10:18 GMT
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/ 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 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 

> 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:
- Changelog: we traditionally have not had a CHANGELOG file. This link 
provided by Dennis

will show you what changed. I'll update our Release Notes, a subpage of , 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 

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:
For additional commands, e-mail:

View raw message