RE: Release Manager for 4.2.0?
> -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
Re: Release Manager for 4.2.0?
On 16/06/2016 Kay Schenk wrote: On 03/27/2016 01:13 PM, Andrea Pescetti wrote: Anyway, there are some issues we need to get done as a team ...before appointing a release manager makes sense: 1) Enough code. Done. The merge of the recent gbuild work totally justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny fraction of the fixes that (at that time) were available on trunk. So here we are already OK, and we've been OK for months. 2) Localization. I got shell access to the Pootle server a few days ago. I'm still looking around, and if someone else want to join this is an important part. We need to have a solid process for updating translations (the full route: new strings in code -> Pootle -> back to code -> in localized builds) in place. As the localization changes are quite significant from 4.1.2 to 4.2.0, can you give us an update on the porting process? Are there instructions, etc? I haven't been able to check all of this yet, sorry. But Infra provided full access in the meantime, meaning that the bottleneck here is only on our side and not on the Infra side. 3) Buildbots and ASF-owned build machines. Buildbots are not essential for a release: 4.1.2 was built (like all previous releases in history) on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we can't use buildbots for it; we need to setup new systems. ... On this. Why can't we use the buildbot assuming we can get all of them working satisfactorily? I know there are, for example, some library upgrades/differences between the buildbots and what we've used in the past, but if we're upgrading to a new version, why can't we just spec this in the system requirements 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). Unfortunately, the discussion on this got stalled on the Infra list when Infra wrote it would be very problematic for them to create VMs for us matching our specifications - they decided to focus on only one, recent, Linux-based distribution for their Linux VMs. There might be solutions involving Docker, but this only makes things more complex. Can we flesh out specs in this direction? New versions of software often dictate system software changes. The major difference would be, I think, in the required glibc version for Linux builds. I really feel we should move on from specialized release build hardware. It is not specialized hardware in itself, it is 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. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org