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.
Difference between revisions of "Planning Council/Cross Project Teams/Aggregation"
(initial document for cross-project team) |
(→Statement of Problem) |
||
| Line 11: | Line 11: | ||
* 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. | * 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 build "builds" feature/product/and plugins (branding and capabilities, I believe). Ideally, we would only aggregate, and not compile anything. {{bug|299344}} |
* 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. | * 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. | ||
| Line 18: | Line 18: | ||
* requires frequent "intervention" to add/remove projects. | * requires frequent "intervention" to add/remove projects. | ||
| + | |||
| + | * The +0, +1, +2 categories are an approximate categorization. | ||
| + | |||
| + | * There is unspecified trade-offs between being "strict" vs. being "lax". For example, in .build files, projects can specify version="" and the highest version in the repo will be fetched or mirrored. But, there's no guarantee that the repo has been updated yet, so in some cases, it might appear to have "built", but is still using a lower than expected version. | ||
Revision as of 01:22, 1 February 2010
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. bug 299344
- 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.
- The +0, +1, +2 categories are an approximate categorization.
- There is unspecified trade-offs between being "strict" vs. being "lax". For example, in .build files, projects can specify version="" and the highest version in the repo will be fetched or mirrored. But, there's no guarantee that the repo has been updated yet, so in some cases, it might appear to have "built", but is still using a lower than expected version.