Priorities in Yearly Simultaneous (Coordinated) Release
This document is a product and responsibility of the Eclipse Planning Council, authored by its chairperson, currently David Williams.
- 03/07/2012 - First version
Introduction and Background
The question of 'priorities' often comes up in the Simultaneous Release -- as it does for anything with finite resources and time constraints. 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" we had to limit the number of projects in the yearly 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 that depend on Eclipse, and is 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 had any substantial impact, that would likely take further, specific and detailed 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".
C. 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).
D. Incubating projects that have never released before would be "lower", projects released before would be "higher".
E. 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, a huge amount of new code to contribute to Eclipse) would be "lower".
It should be noted that there are other types and sources of priorities, and we (Planning Council) have tried to limit ourselves to discussing those most related to producing the yearly release (since that is our mission and charter). But, will document some of those other types and sources we discussed, since they are interesting and important in general.
For example, there might be a security vulnerability that required a CQ review to fix (e.g. new version of a third party library), and that would normally receive high priority and immediate attention (if not also high priority "patches", etc.).
Another example, projects that are part of the LTS (Long Term Support) program would normally be "higher" than those not, but the LTS program is a separate entity governed by their own steering committee and is to technically independent from the yearly release (though, of course, with high degree of overlap).
Note also, while not part of a project's priority, per se, some teams might have their own priorities that fits in with their specific workflow. For example, the IP Team might see 3rd party packages required by many projects as "higher priority" than 3rd party packages required by only one project. Similarly, CQs that are for a minor revs on existing packages are usually simpler to do, thus might be considered "higher" priority (doing a lot of those first), whereas completely new, especially large, complex packages, might be considered "lower priority".
Similar non-project priorities could be associated with build tasks, for example, builds could be a higher priority than unit tests, and "niceness" levels should be used by projects to take such priorities into into account. Another example, if one job or one project's tests are found to be "hogging" the build infrastructure, they might be asked to stop what they are doing until a "fix" can be found for what ever is causing the overload (even if not the project's fault).
Hopefully this document helps make it clear that there priorities at play at Eclipse (as there would be anywhere) but that Eclipse in general, and the Planning Council specifically, like to document such things to be as open and transparent as possible.