Revision as of 16:09, 12 February 2013

Purpose

This document is the plan, and working notes for moving to CBI-based builds. There is still lots to do, and many changes to make, so want to be sure as much is communicated as best as possible.

We want to be aggressive in adopting CBI based builds for Kepler, but at the same time, responsible. That is, to make sure it is correct -- or, correct enough -- that adopters (or, ourselves!) are not broken by any changes. And, that means "correct enough" from one I-build to the next, not "just by the time we release". This is a new area for most of us so will take a lot of focus.

The following are the major criteria to judge if/when we are ready to adopt as our primary build and/or release. Any others?

Main Criteria for moving to CBI based build for Kepler

1. Have same output deliverables as current build: zips, repository, etc. (For Equinox and Eclipse)
2. (Be able to reproduce exact same build, given a tag (or tags) to start the build with.)
3. Same warnings (and compile errors, if any) as PDE based build.
4. Be able to run our JUnit tests, with same results, as PDE based build.
5. Produces the same Java Doc and Help documentation.
6. Run a binary comparator against the bundles to ensure that they are the same binary content as the regular bundles.
   1. [Not sure how to do this since "qualifier algorithm" is different].
7. Qualifiers not change (except for branding bundles) if the content has not changed.
8. All bundles signed.
9. Final I-build type repository have same content and metata as PDE based build (nothing missing, nothing extra).
10. Be easy to fit in to current workflow of automated builds and tests of "nightlies", I-builds, milestones (i.e. committers have to know

what to do to "release" something for a build, how to "freeze" changes at a certain point).

Bug queries and reference documents

• Buq query for open CBI bugs (in platform, releng).

• Bug query for open Eclipse Foundation CBI bugs (all in Eclipse Foundation, CBI)

• See Platform-releng/Platform_Build for steps to do local builds and tests.

• See Platform-releng/Automated_Platform_Build for specifics of automated builds.

• URL for CBI based builds (temporary, just until we "switch"):

http://download.eclipse.org/eclipse/downloads/cbibasedindex.html

Rollout and deadlines

Weeks below are numbered in "milestone weeks", beginning with "towards M6" ... there are only 6 weeks for M6.

Towards M6

Week 2: (2/11 - 15)

Begin to produce daily automated CBI based builds and run unit tests in parallel with PDE-based builds.

I'll schedule these to start at 8:11 PM, same time as PDE-based Nightlies and same time as weekly I-builds.

Initially, all CBI based builds (even "nightlies") will be "I-builds" to better assess versioning, and more work is need to implement "nightly vs. integration" builds.

I builds will build against master, controlled by repositories.txt

(Unit tests on Linux only, until those work as expected, to save Windows and Mac machine resources).

During this week "announce" the CBI based builds available, get community/adopter help in testing adequacy.

Committers should begin to use SDK's produced, and evaluate for correctness. In particular:

Check that version numbers change (or don't change) as expected. (I recommend you make some change, even trivial, to make sure it "gets in to" a build, if not otherwise planning changes this week).

Those with "binary bundles" check that they are correct ones.

Help evaluate failing JUnit suites. Some may be "releng" issues, but some may be project pom issues?

Initial Limitations: (meaning of priorities: high, need before making primary; medium, need before release; low, probably need at some point)

there will be no "autotagging" of aggregator or repositories, until we are more confident. (medium priority)

there will be no "equinox drops". (low/medium priority)

there will be no cbibased "I-build repo" (high priority)

"zipped repos" are known not to be quite right yet (low prioriy)

no ecj.jar produced (in hands of JDT Team? To tweak their "custom script"?) (low priority)

no "auto update" of pom's, based on manifest ... such as committers have to update version number in both, make "build.properties" changes in both. (low priority)

Week 3: (2/18 - 22)

Cut over to CBI based builds as primary (unless someone raising a true, blocking objection).

Begin to tag aggregator upon successful build, (with "commits" of latest submodules added to aggregator).

(This allows "local build" to duplicate our build following directions given at Platform Build wiki)

TODO: someone (Thanh?) should confirm it gives same "target" results?)

Begin to produce "4.3-I-build" repositories at .../eclipse/updates.

Week 4: (2/25 - 3/1)

Possibly this week start to have true "CBI nightlies" vs. "Integration".

Post SR2: could we (or should we?) produce 4.2.2+ maintenance builds for comparison to 4.2.2 -- or is that all in LTS hands now? These would not really be "for consumption", but some pom namespace changes need to be made for LTS in all module poms.

Week 5: (3/4 - 8)

Week 6: (3/11 - 15) <== 3/15 is M6+0 day.

Milestone stabilization week