> -----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). [ ... ] > [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. 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. 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. Runtime is preferable to prevent failures when there are OS updates or upgrades that don't require re-installation of application software products. 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
