Build Environment Effort/Customers

From Apache OpenOffice Wiki
Jump to: navigation, search


Build Environment Effort

Quick Navigation

About this template

"Customers" of the OOo build environment are all people or groups of people that either use it or immediately take the results of a build and process it. Here's a list of customers or potential customers, scenarios how they use our build environment or where they could use it in future. In some case there are also some descriptions of how thinks work in these scenarios. Nothing in the following list is meant as a "requirement" for our future build environment, but hopefully we can derive them from the scenarios and descriptions. The list will be completed by surveys and interviews.

Frequent or professional OOo core developers (*)

  • create CWS and bootstrap build environment for it
  • work on one platform most of the time, but at least at the end of the CWS life cycle want to get builds on other platforms too
  • work spaces need rebasing from time to time
  • sometimes a CWS builds upon a CWS that is already approved by QA but still not integrated
  • build breakages not found on master can cause significant interruptions
  • currently in most cases doing a full build is not an option as it takes too long because too much stuff needs to be built
  • current way of handling dependencies allows to avoid to build too much in case of "compatible" changes, but builds too much for "incompatible" ones
  • for the majority of libraries real unit tests are impossible as we require to first finish the build, install office and then execute the tests
  • a base line compatible build can not be expected always

Release Engineering and Release (Program) Managers

  • most builds are done "compatibly", means: no modules will be built from scratch
  • at times a build is done "incompatibly" starting from a particular module (as requested by a developer)
  • at times a build is done from scratch
  • creating milestone builds
    • OOo: in Hamburg currently two builds (pro,nonpro) on 5 platforms each, language support for currently building 20 and packing 5 languages on DEV300
    • SO: currently two builds (pro,nonpro) on 5 platforms each, language support for currently 16 languages on DEV300
  • creating release builds
    • OOo: in Hamburg currently one build (pro) on 5 platforms, language support for currently building 20 and packing 5 languages on DEV300
    • SO: currently one build (pro) on 5 platforms each, language support for currently 16 languages on DEV300
  • due to the huge number of products to be built fast packaging is important
  • the Hamburg environment allows to provide many "cores", so optimizing for parallel builds is important
  • in Hamburg builds are carried out using a "base line environment" that is considered to be an optional part of the build environment
  • PM also releases extensions, not necessarily at the same times as OOo

Additional duties:

  • The Hamburg release engineers are the main build environment maintainers
    • the smaller the differences between the general and the Hamburg build environment, the smaller the effort
  • Release (Program) Managers take release builds and care for deployment
  • Release engineers carry out code integration into the master code line before they start the builds
    • merge conflicts and build problems caused by merges are the major reason for slow integrations and thus add to the problem of too large milestones releases cycles

Occasional OOo developers

  • They often are overwhelmed by the size and complexity of OOo and its build environment
  • They usually work on small parts of OOo at a time
  • They are repelled by a lot of "alien" stuff in our build environment that they never see elsewhere
  • They have to download/upload/rebase/build much more stuff than they would like to
  • configure needs to much fiddling until it runs through
  • CWS tooling looks like overhead, especially if it takes a lot of time to follow it
  • Especially Windows developers miss IDE support

Extension developers

  • All Sun extensions are part of the OOo repository
  • Binfilter isn't an extension
  • Some extension modules have build dependencies on OOo modules (why?)

Build Bots and Tinderboxes

SDK users

  • The SDK build environment is totally different
  • makefiles can't be shared
  • Java extensions can be built with NetBeans

Localization providers (**)

  • Currently localization providers can't check their contributions directly as their input needs merging and a build done in Hamburg
  • This creates large turnaround times for bug fixing and prevents easy handling of localization patches
  • since the ContinuousL10N process is in place translations are integrated in every masterbuild

Help content providers (**)

  • Adding new or changed help content currently always needs a full build environment QA (*)

(*) includes users of current Hamburg Build Environment and Sun QA

(**) these groups currently don't use the build environment, but simplifying it so that it can enable them to test their work by themselves directly is worth an evaluation

Personal tools