SimRel/Priorities

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 is, 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 had to 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 transparency 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 responsible to actually solve the problem of resource shortages, not the Planning Council, and not these priorities.

Priorities related to Planning Council and the Yearly Release

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 if that was ever needed or useful.

It should be noted that these are priorities for producing a timely, predictable release train for adopters, products, and projects that depend on Eclipse projects, and these priorities are not that related to the 'importance' of a project, which would 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 (such as, perhaps 'importance'). 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, and so the community and eco-system will be better aware of them and have a rough idea of what to expect.

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".

Other priorities

It should be noted that there are other types and sources of priorities, and we (the Planning Council) have tried to limit ourselves to those related to producing the yearly release, since that is our mission and charter. But, we 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 very 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 part of it. The LTS program is a separate entity governed by their own steering committee and is 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 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 (thereby satisfying maximum clients with fixed amount of time). 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" (again, to maximize quantity).

Similar non-project priorities could be associated with the build infrastructure. For example, builds would be a higher priority than unit tests, and "niceness" levels should be used by project's builds and tests 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) just so others do not get slowed down.

Concluding Remarks

Hopefully this document helps make it clear that there are priorities at play at Eclipse (as there would be anywhere) but that Eclipse in general, and the Planning Council in particular, like to document such things to be as open and transparent as possible. Please discuss with your Planning Council representative if you have issues, questions, or exceptions related to your project.

This document will likely be updated from time to time (probably about once per year) as new things are learned, and some of these concepts become more formalized.