Difference between revisions of "SimRel/Priorities"

From Eclipsepedia

Jump to: navigation, search
(initial draft of priorities document)
 
m (added Luna category)
(21 intermediate revisions by one user not shown)
Line 1: Line 1:
 
= Priorities in Yearly Simultaneous (Coordinated) Release =
 
= 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]
+
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 ==
 
== 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 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 ==  
+
== 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.  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 further discussion or sanity checking at the Planning Council. This list of priorities is just to seed any such discussions; to have them documented ahead of time, so the community and eco-system might be better aware them.  
+
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".
 
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.  If projects are used in EPP Packages, they would be "higher", if not in EPP, "lower".  
+
B.  Projects that are used in EPP (Eclipse Packaging Project) Packages, would be "higher"; those not "lower".  
  
C. If projects are late in meeting deadlines, they would be lower, those on-time "higher". For example, getting into the aggregation build (M4 for newly participating projects) or getting plans done (M4).  
+
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".  
 
D. Incubating projects that have never released before would be "lower", projects released before would be "higher".  
  
E. Projects with no (new) 3rd party dependencies would be "higher", projects with a few would be "medium", but projects with many new and distinct 3rd party dependencies (or simply new code to contribute to Eclipse) would be "lower".
+
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.
  
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".  
+
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.
  
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.
+
[[Category:Luna| ]][[Category:Kepler| ]][[Category:Juno| ]]

Revision as of 12:28, 1 October 2013

Contents

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.