You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andrea Pescetti <pe...@apache.org> on 2016/07/09 12:20:26 UTC
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Release Manager for 4.2.0?
Posted by Kay Schenk <ka...@gmail.com>.
On Sat, Jul 9, 2016 at 9:52 AM, Dennis E. Hamilton <de...@acm.org>
wrote:
> > -----Original Message-----
> > From: Andrea Pescetti [mailto:pescetti@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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
RE: Release Manager for 4.2.0?
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Andrea Pescetti [mailto:pescetti@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org