openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Release Manager for 4.2.0?
Date Sat, 09 Jul 2016 16:52:28 GMT
> -----Original Message-----
> From: Andrea Pescetti []
> Sent: Saturday, July 9, 2016 05:20
> To:
> 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.

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

View raw message