On Sat, Jul 9, 2016 at 9:52 AM, Dennis E. Hamilton
wrote:
> > -Original Message-
> > From: Andrea Pescetti [mailto:pesce...@apache.org]
> > Sent: Saturday, July 9, 2016 05:20
> > To: dev@openoffice.apache.org
> > Subject: Re: Release Manager for 4.2.0?
> [ ... ]
> > We have a "baseline", minimal system requirements that are supposed to
> > be valid for all the 4.x releases. We build releases on old (but still
> > supported) system to guarantee maximum compatibility for users. No ASF
> > buildbots match our baseline (they are all more advanced).
>
Yes, we do have minimal baseline user system requirements, if you are
referring to:
http://www.openoffice.org/dev_docs/source/sys_reqs_aoo41.html
I understand this. What I'm not in agreement with is extending both our
current "official" distribution build platform environments and these base
user requirements beyond the 4.1.x release.
But, it is true that non of the ASF buildbots satisfy our distribution
requirements in any case, and what do we want to do about this?
[more below]
[ ... ]
> > [Building this way involves] a fairly ordinary system
> > that is "specialized" since it is only available to one person. The best
> > thing would be to get the same system moved to ASF-owned VMs, accessible
> > to all PMC members who want to do so.
> [ ... ]
> At present, the discussion with
> > Infra is stalled as explained above.
> >
> [orcmid]
>
> It seems to me that we are seriously over-constrained here.
>
> The requirement that anyone should be able to build something akin to what
> we build to know a release candidate is acceptable (or for their own
> purposes) seems difficult to meet since the way current distributed
> binaries are prepared is with unknown settings and build configuration
> (including library, compiler and tool [version] dependencies). Somehow
> that information must be captured and provided as part of the released
> source, giving others an opportunity to identify and address
> reproducibility problems.
>
@Dennis, the build settings and environments are documented in:
http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.2/
The file at the top level:
http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.2/environments.txt?view=log
gives a bit more detail on the system environments but you'd have to search
out details for say CentOS5 to see what actual versions of libraries, etc
pertain.
> Having buildbots not at those same levels means that we can't assume
> buildbots provide binaries that work for the current oldest-supported
> platform for an AOO major version.
That is absolutely correct and something I experienced on CentOS 6.7 a few
months ago. I could install but not run the Linux-32 bit AOO from the
buildbot due to glibc version differences.
> Is it not the case that buildbots mainly provide a smoke test on the
> build process? Verifying anything further depends on what developers do
> with the result. (PS: I can't imagine reverting to Windows XP for a
> buildbot.)
>
> It might not be necessary to build on the same platform version that an
> executable is intended to run on. The idea might be to build for the
> lowest-level of supported OS/runtime version. Would not appropriate
> confirmation be by installation and operation on the lowest supported OS
> version and also the latest, hoping there is no smoke or breakage at either
> end?
>
> If there are breaking changes between the two ends of our confirmed
> operability, the question is then whether or not we provide adaptation at
> installation or at runtime.
Currently we provide changes at installation due to our build process
nature.
Runtime is preferable to prevent failures when there are OS updates or
> upgrades that don't require re-installation of application software
> products.
>
I'm pretty certain this is not possible under our current architecture. We
use certain libraries for building, and we're basically a static monolithic
build at the end. I don't think our build process or architecture lends
itself to this kind of dynamism. A more knowledgeable developer than I
could certainly weigh in here. I think we would have to essentially retool
core components into something like extensions to enact what is suggested.
>
> Without such provisions, we will also fail to take advantage of advances
> in the platform that users see with other software products. I am thinking
> of differences such as the font formatting and scaling issues introduced in
> Windows 7 and later, the changes of Java location on OS X, and encryption
> libraries on *nix flavors. The OS certification and code signing
> requirements for latest Windows and Macintosh versions also apply here.
> There's more.
> I'm not saying that we should change our approach to what is supported.
> Somehow, we must remove the brittleness from how we accomplish that and how
> others can confirm/reproduce it.
>
> - Dennis
>
>
>
>
>
>
> -
