Difference between revisions of "Efforts/Packaging"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Tasks)
m (Tasks)
Line 28: Line 28:
 
{|border="1" cellspacing="0" class="wikitable"
 
{|border="1" cellspacing="0" class="wikitable"
 
|- style="background:#efefef;"  
 
|- style="background:#efefef;"  
! Title !! Effort
+
! Title !! State !! [[CWS]] !! Owner !! Target
 +
|-
 +
! colspan="6" align="center" | [[ODF_Toolkit/Efforts/OOo_without_URE|Extract URE]]
 +
|-
 +
| Adapt code base to OOo/etc. installations where the URE parts are installed separately from the rest (i.e., an OOo/etc. installation spans two directory trees). || style="background:lightgreen;" | done || sb71 || sb || OOo 2.4
 +
 
 +
|-
 +
| [[Efforts/Package_Restructuring/Product_Inventory|Product Inventory]] || style="background:lightblue;" | open || || || immediate
 
|-
 
|-
 
| [[Efforts/Package_Restructuring/Modelling|Model Products from a Program Managers Perspective]] || style="background:lightyellow;" | --
 
| [[Efforts/Package_Restructuring/Modelling|Model Products from a Program Managers Perspective]] || style="background:lightyellow;" | --

Revision as of 13:55, 25 January 2008

Type: Effort Status: in progress Owner: Stephan Bergmann (Kay Ramme)

OpenOffice.org (OOo) and its derivatives are complex products. Many features, templates, configuration files, registry entries, binaries, localizations etc. need to be delivered and deployed in a reliable and platform compliant way, while giving the user broad choice regarding the particular features he wants to actually install.

OOos growing ecosystem brings the current approach to its limits, we are currently facing a set of problems, which the below proposed solution is going to address. OOo based products need to support different platforms (Operating System / Machine Architecture) as well as different deployment systems (e.g. RPM, Debian Packages, Ports, Solaris Packages, MS Windows Installer), localizations and feature sets, as well as they need to be easy to extend and maintain.

Goal

The Package Restructuring project aims to improve the overall OOo packaging structure, to

  • ease testing,
  • improve build performance,
  • ease introduction of new, updated or derived products (shopping cart approach),
  • simplify maintenance.

Problem

  • Overlap of OOo and OOo based products, such as the URE, OOo[locale], StarOffice, OOo[machine] etc.
  • Custom brands and localization can only be provided as part of building OOo.
  • High QA efforts, as every deliverable needs to be tested.
  • Every update / patch as an independent product again.
  • Extensions are not maintainable as system packages.

Solution

Step by step reduce the overall number of different packages (parts) by reducing redundancies, such as same files, same short cuts etc, by consolidating them into dedicated packages. E.g. different installation sets for different languages are going to share all but the locale specific packages (parts). QA efforts may than be reduced by deriving a products test status from the packages (parts) test status, means if all packages (parts) of a product have been tested, than the product has been tested.

Time Frame

First big changes are planned to be ready with OOo 3.0.

Tasks

Title State CWS Owner Target
Extract URE
Adapt code base to OOo/etc. installations where the URE parts are installed separately from the rest (i.e., an OOo/etc. installation spans two directory trees). done sb71 sb OOo 2.4
Product Inventory open immediate
Model Products from a Program Managers Perspective --
Java Installer to support arbitrary repository and package managers --
Java Installer to rely on provisions / dependencies only --
Basic De-Composition (Uno,Bases/Core/Apps,Brand,localization) --
Find a way to update MS Windows Installer Components in a product independent way --
Personal tools