Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Priorities in Yearly Simultaneous (Coordinated) Release
This is a working document, in the process of being proposed and reviewed. It is proposed to eventually be on Planning Council wiki, as a Planning Council Policy.
- Discussed some at Planning Council call on February 1 and suggestions incorporated. Will discuss more at March meeting.
Introduction and Background
The question of 'priorities' sometimes comes up in the Simultaneous Release. For example, the order that CQs are evaluated are in part based on some type of priority. Occasionally the question has come up "what if" we had to ration the build machine infrastructure? Even, from time to time, the question comes up "What if, due to resource constraints, we had to limit the number of projects in the June Release and defer some until a few months later?" This page is to document some of the priorities that are important, from the Planning Council's point of view. They are documented here primarily for openness and perhaps others can find them useful. To be explicit, if there ever were "resource constraint problems", then the parties responsible for those resources would be the ones to actually solve the problem of resource shortages, not the Planning Council, and not these priorities.
The following principles are in approximate order of importance. But, the details of how to quantify and combine (weigh) these different types of project priorities is not fully specified, thus there could not be an algorithm that came up with one priority per project. Perhaps, over time, heuristics could be developed to assign projects to 5 or 7 "buckets" of priorities. It should be noted that these are priorities for producing a timely, predictable release train for adopters, products, and projects, and not that related to the "importance" of a project, which could depend on factors such as innovation, demand, quality, and others. Also, there would always be special cases that didn't well fit in with this list of priorities. Therefore, if there ever was a question of assigning priorities to projects, that would likely take specific, further discussion at the Planning Council. This list of priorities below is intended to seed any such discussions; to have them documented ahead of time, so the community and eco-system will be better aware them.
A. Projects with more dependent projects in the Simultaneous Release would get a higher priority. So, +0 and +1 projects would be "high", +2 "medium", and +3 (leaf projects) "low".
B. Projects that are used in EPP (Eclipse Packaging Project) Packages, would be "higher", those not "lower".
Projects part of the LTS (Long Term Support) program would be "higher", those not "lower".
D. Projects that are late in meeting deadlines, would be "lower", those on-time "higher". For example, getting into the aggregation build (M4 for newly participating projects) or getting plans done before the deadline (M4).
E. Incubating projects that have never released before would be "lower", projects released before would be "higher".
F. Projects with relatively normal amount of CQ's would be "higher", projects with an abnormally high or unusual number of new and distinct 3rd party dependencies (or simply new code to contribute to Eclipse) would be "lower".
Note, while not part of a project's priority, it should be noted that 3rd party packages required by many projects would be "higher", and 3rd party packages required by only one project would be "lower". Similarly, any CQ submitted before the M5 deadline would be "higher" while those after the deadline would be "lower" (if not "very very low"). Similarly, CQs that are for a minor revs on existing packages are simpler to do, thus would be considered "higher" priority, whereas completely new, especially large, complex packages, would be considered "lower".
Similar non-project priorities could be associated with build tasks, for example, builds would be a higher priority than unit tests, and "niceness" levels should be used by projects to take such priorities into into account.