Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Planning Council/Cross Project Teams/Aggregation
< Planning Council | Cross Project Teams
Revision as of 04:10, 6 January 2010 by Unnamed Poltroon (Talk) (initial document for cross-project team)
Members
John Arthorne (Platform) Thomas Hallgren (Buckminster) David Williams (WTP)
Statement of Problem
The current "Helios Builder", has many strong points, but some weaknesses as well:
- It is not truly reproducible. There are two sources of input, specification (.build) files from cvs, and project's repositories. We only have control over the CVS part, (it can be tagged, etc.) but Projects can change their repo at any time (either on purpose, or accidentally). This chance can cause the build to fail, but can also still succeed, but be a different set of bits than previous runs.
- The current build "builds" feature/product/and plugins (branding and capabilities, I believe). Ideally, we would only aggregate, and not compile anything.
- The current builder/aggregator "fails" if anything is wrong. Even if it is only a leaf node. At times, this requires tweaking the "build model" to get the build operational again, while waiting for the leaf node to correct itself. It would be better if the build tried to "work" even if some components were in error, so that tests, etc., (that don't depend on leaf node in repo) can get started.
- When the build fails (due to conflicting dependencies, etc.) it is hard to figure out the root of the problem, without a p2 trained eye.
- requires frequent "intervention" to add/remove projects.