OpenOffice64

Differences between revisions 6 and 7
⇤ ← Revision 6 as of 2005-11-04 17:32:52 →
Size: 3283
Editor: 209
Comment: add stuff from approval
← Revision 7 as of 2005-11-04 21:25:34 → ⇥
Size: 3152
Editor: 242_220_103_66-WIFI_HOTSPOTS
Comment: Address comments by Fabio
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
 * Native packages are currently built for amd64, but the build is broken intentionally after the packages are built. Change the packaging such that native packages (suffixed -experimental-dont-complain-if-it-doesnt-work or something similar) are produced, which conflict with the i386 packages. Both builds should be uploaded and tested in the dapper archives.  * Native packages are currently built for amd64, but the build is broken intentionally after the packages are built. Change the packaging such that native packages (suffixed -experimental-dont-complain-if-it-doesnt-work or something similar) are produced, which conflict with the i386 packages. Both builds should be uploaded and tested in the dapper archives, but the experimental builds should go to universe.  They should be announced on ubuntu-devel-announce and possibly ubuntu-user.
Line 27: Line 27:
   * basic tests, not specific to amd64 (FormalTestPlans). These have to be written down and integrated into the FormalTestPlans.    * basic tests, not specific to amd64 (FormalTestPlans). These have to be written down and integrated into the FormalTestPlans. Until FormalTestPlans is ready, basic operation such as opening a document, writing some text into it, format it, close the document, reopen it and then print it and make sure that works for each of the applications) would be a good start. Bugs and error reports should go to Malone.
Line 36: Line 36:

=== Approver comments ===

FabioMassimoDiNitto:

 * Please add estimate amount of time required to produce 64bit clean pkgs.
 * Define what media you want to use to distribute the test pkgs and how to involve the community to test them)
 * Define a list of basic tests that could be performed and how to collect these reports. (FormalTestPlans is not complete yet).
 * You probably want to use FeatureFreeze as deadline to decide what pkgs you want to ship.
 * What kind of sub-tasks do you plan to bounty? what if nobody picks them?

Summary

OpenOffice.org currently is built on amd64 using the i386 binaries, because the application is not yet completely ported to 64bit. Evaluation of the current state of the 64bit native build of OOo2 on amd64 is needed. Decide between the 64bit build and the current practice of using the 32bit build on amd64.

Rationale

It's a burden to separately maintain the i386 packages (prepackaged i386 libraries and applications) for amd64. If the application is 64bit clean, a lot of maintainance effort can be saved.

Current issues with the 64bit builds are:

  • bugs in the UNO bridge
  • crashes and failures when loading documents, and which are not seen on 32bit architectures.

Implementation

  • Native packages are currently built for amd64, but the build is broken intentionally after the packages are built. Change the packaging such that native packages (suffixed -experimental-dont-complain-if-it-doesnt-work or something similar) are produced, which conflict with the i386 packages. Both builds should be uploaded and tested in the dapper archives, but the experimental builds should go to universe. They should be announced on ubuntu-devel-announce and possibly ubuntu-user.
  • Continue to build the i386 based packages for amd64 (update the ia32-* packages as well).
  • Follow the upstream milestones for packaging (leading to 2.0.1, 2.0.2, 2.0.3 ...)

  • Make a test plan how to compare the two builds and check the uploads according the test plan. Details for OpenOffice testing are collected at OpenOfficeTesting. Feedback should be provided in bug reports for Malone.

    • basic tests, not specific to amd64 (FormalTestPlans). These have to be written down and integrated into the FormalTestPlans. Until FormalTestPlans is ready, basic operation such as opening a document, writing some text into it, format it, close the document, reopen it and then print it and make sure that works for each of the applications) would be a good start. Bugs and error reports should go to Malone.

    • some whitebox tests, targeting problematic areas, where 64bit issues are known to exist. These tests should be collected on OpenOfficeTesting for now.

  • Decide which version to ship with dapper, based on those test results.

Outstanding issues

  • Determine a date when the decision for i386/amd64 binaries has to be made (DapperReleaseSchedule). It's basically not a new feature (which should be ready for FeatureFreeze), but just a (rather large) implementation detail.

  • The packaging of the amd64 packages is mostly done (pending the suffixed package builds). There is currently no estimate how much time is required to have the same functionality/quality for the 64bit port.
  • Some sub-tasks which could be subject to a bounty might be identified. It's unclear to identify these subtasks and how to identify the amount of work required.

OpenOffice64 (last edited 2008-08-06 16:41:47 by localhost)