Planning Council Exception Process:
←Older revision
Revision as of 01:57, 29 November 2012
(2 intermediate revisions not shown.)
Line 154:
Line 154:
== Required for good adoption ==
== Required for good adoption ==
-
The items in this category are, in a sense, optional. That is, what, exactly, is done by a project is
up to that project
, but
+
The items in this category are, in a sense, optional. That is, what, exactly, is done by a project is
optional
, but
-
it is required for projects to '''document''' what they do. These are often "best practices" that many projects have found essential at driving good adoption, plus the items sometimes speak to the quality of the project
,
as an Eclipse "good citizen", as opposed to their code quality or architecture. But, their importance is not be as universally relevant to all projects
. Hence
, it is required that each project document what they do for these items, but exactly what they do is up to the best judgment of the project and their community.
+
it is required for projects to '''document''' what they do. These are often "best practices" that many projects have found essential at driving good adoption, plus the items sometimes speak to the quality of the project
(quality
as an Eclipse "good citizen", as opposed to their code quality or architecture
)
. But, their importance is not be as universally relevant to all projects
and their adopters
,
hence
it is
only
required that each project document what they do for these items, but exactly what they do is up to the best judgment of the project and their community.
=== Engage Community ===
=== Engage Community ===
Line 167:
Line 167:
=== Performance ===
=== Performance ===
-
Project should have measurable performance criteria that are regularly tested against. Projects should devote at least one milestone to performance and scalability improvements. This is important to the Simultaneous Release since a project or plugin by itself might seem to perform ok, taken together as part of hundreds of bundles, might
result
in unusable performance
.
+
Project should have measurable performance criteria that are regularly tested against. Projects should devote at least one milestone to performance and scalability improvements. This is important to the Simultaneous Release since a project or plugin by itself might seem to perform ok,
but
taken together as part of hundreds of bundles,
it
might
cause
in unusable performance.
-
+
-
=== Capabilities ===
+
-
+
-
Each project should provide basic capability/activity definitions to allow for their UI contributions to be hidden. These can be provided in a separate plugins and feature to facilitate inclusion and reuse by consumers, or ... as most projects do ... simply document some examples, so adopters can create their own, or reuse via copy/paste. Ideally, projects should also provide triggers to facilitate progressive discovery of functionality (but, not many do, other than the Platform). As with other "good citizen" items, projects are free to document "we don't do this" ... but, then at least it is known and better communicated.
+
-
+
-
[removed 11/23/11] Good idea, but there is nothing in "release train" that depends on this (only one EPP package uses capabilities and does not depend on this requirement), and adopters that use it likely already understand how to do it, so removed requirement to simplify list. And, to emphasize, that's not to say the concepts behind products using capabilities are not important ... they are ... just nothing as a release train we can do to help much
.
+
=== Builds ===
=== Builds ===
Line 202:
Line 196:
The main [http://www.eclipse.org/articles/article.php?file=Article-Accessibility351/index.html accessibility article at Eclipse Corner] is also very helpful. (thanks goes to Todd Creasey).
The main [http://www.eclipse.org/articles/article.php?file=Article-Accessibility351/index.html accessibility article at Eclipse Corner] is also very helpful. (thanks goes to Todd Creasey).
-
-
=== APIs ===
=== APIs ===
Line 219:
Line 211:
Projects should define and document their retention policy. This should include both zip distributions and repositories. For examples, see [[WTP/Retention Policy|WTP Retention Policy]] and [[Eclipse Project Update Sites|Eclipse Project Update Sites]].
Projects should define and document their retention policy. This should include both zip distributions and repositories. For examples, see [[WTP/Retention Policy|WTP Retention Policy]] and [[Eclipse Project Update Sites|Eclipse Project Update Sites]].
+
=== Make it easy to get released source from repository ===
-
=== Project Metrics ===
+
Projects should
make it easy for potential contributers (
and
adopters)
to
get
the
source used in
the release,
from the source control repository (that is
,
source that exactly matches what was used
in
a build or
release
). This might be done by some form of documentation
,
or tag, or
by
producing a
[http://
help
.
eclipse
.
org
/
juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-cvs-project-set.htm "team project set"
]
during your build
and
making that available from your downloads page
.
-
+
-
Projects should
provide some summary metrics, such as number of bundles, number of committers, lines of code, number of bugs opened
and
fixed. This is so some statements can be made and tracked year-
to
-year about
the
size of
the
simultaneous
release
.
+
-
+
-
[removed 11/23/2011] Again
,
a good idea
,
but nothing
in
"
release
train" depends on this
,
nor do adopters need anything other than what is provided
by
Eclipse Foundation itself, via "dash" and project pages. Some projects submit their repository to
[http://
www
.
ohloh
.
net
/
Ohloh
]
(or similar)
and
let it produce project stats
.
+
-
+
-
=== Make it easy to get released source from repository ===
+
-
[added
10
/
18
/
2011
]
+
Another good way to accomplish this, while maybe not suitable for all projects, is to make your bundle's source repository "self documenting" by using the
[
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Ftasks%2Fui_import_from_cvs.htm Eclipse-SourceReference directive] in your manifest.mf file (its very easy to have this
added
if your build makes use of [http://help.eclipse.org
/
indigo
/
index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Freference%2Fpde_builder_config.htm PDE build or its properties
]
). This requirement serves two purposes.
-
Projects should make it easy for potential contributers (and adopters) to get the source used in the release, from the repository (that is, source that exactly matches what was used in a build or release). This might be done by some form of documentation, or tag, or by producing a [http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-cvs-project-set.htm "team project set"] during your build and making that available from your downloads page. Another good way to accomplish this, while maybe not suitable for all projects, is to make your bundle's source repository "self documenting" by using the [http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Ftasks%2Fui_import_from_cvs.htm Eclipse-SourceReference directive] in your manifest.mf file (its very easy to have this added if your build makes use of [http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Freference%2Fpde_builder_config.htm PDE build or its properties]). This requirement serves two purposes.
First, we want to be sure adopters can get your source used in a release, in case they need to create some fix, even at some distant point in the future. But, also, this serves the community purpose of making it easier for contributors to provide patches for bugs.
+
First, we want to be sure adopters can get your source used in a release, in case they need to create some fix, even at some distant point in the future. But, also, this serves the community purpose of making it easier for contributors to provide patches for bugs.
=== Excel in National Language support ===
=== Excel in National Language support ===
Line 238:
Line 225:
===== Use the best NL Java Libraries (ICU4J) =====
===== Use the best NL Java Libraries (ICU4J) =====
-
Projects should use [[ICU4J]], where they have "user strings", in order to excel in NL support. (The latest ICU4J bundles will be in Orbit).
+
Projects should use [[ICU4J]], where they have "user strings", in order to excel in NL support. (The latest
recommended
ICU4J bundles will be in Orbit).
===== Use the most efficient message bundles =====
===== Use the most efficient message bundles =====
-
Projects
must
use [http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/misc/message_bundles.html Eclipse message bundles] unless there are technical reasons not to, since (with or without translations) these are known to be more memory efficient that some other forms of handling UI-releated strings. This is important to Eclipse and adoption is some adopters end up using thousands of
bunldes
... so, that's a lot of
string.
+
Projects
should
use [http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/misc/message_bundles.html Eclipse message bundles] unless there are technical reasons not to, since (with or without translations) these are known to be more memory efficient that some other forms of handling UI-releated strings. This is important to Eclipse and adoption is some adopters end up using thousands of
bundles
... so, that's a lot of
strings!
===== Support translations =====
===== Support translations =====
Line 250:
Line 237:
==== Enable development for all languages ====
==== Enable development for all languages ====
-
Projects should design and test for enabling development for all languages including bidi, unicode characters, etc. This is different than "translating" the User Interface
software
and would apply even to "runtime only" components. For one example, while using an English version of Eclipse Web Tools Platform, someone should be able to create a Chinese language web application and have it (and debug logs) displayed correctly.
+
Projects should design and test for enabling development for all languages including bidi, unicode characters, etc. This is different than "translating" the User Interface and would apply even to "runtime only" components. For one example, while using an English version of Eclipse Web Tools Platform, someone should be able to create a Chinese language web application and have it (and debug logs) displayed correctly.
= Additional Information =
= Additional Information =
Line 258:
Line 245:
Exceptions for any rule or schedule can be made if there are good enough reasons to. This same exception process will be followed for things like "requests to respin" a build after a deadline. The process to get any exception must be open and well documented and follow these steps:
Exceptions for any rule or schedule can be made if there are good enough reasons to. This same exception process will be followed for things like "requests to respin" a build after a deadline. The process to get any exception must be open and well documented and follow these steps:
-
First, the Project's PMC must approve the request for an exception and it is the PMC (not the Project) that makes the request to the Planning Council. The Planning Council member that represents the PMC
would
bring the issue forward to the Planning Council.
+
First, the Project's PMC must approve the request for an exception and it is the PMC (not the
lone
Project
or committer
) that makes the request to the Planning Council. The Planning Council member that represents the PMC
is the one to
bring the issue forward to the Planning Council.
Second, the exception requires at least 3 positive votes from active Planning Council members and no negative votes. When time is a factor (e.g. requests for rebuilds) the deadline for voicing a negative vote is basically by the time 3 votes are documented. But when time is not a factor, such as when requesting an exception to one of the criteria, then a period of one week will pass before being final, to allow times for concerns or negative votes to be voiced even after 3 positive votes. If there are not enough positive votes within one week, then the request for exception will be considered 'failed'. Note that "3" was chosen under the assumption that the Planning Council member representing the PMC would vote for it (since that PMC must approve it initially) so that means 2 others must also vote for it, for 3 total.
Second, the exception requires at least 3 positive votes from active Planning Council members and no negative votes. When time is a factor (e.g. requests for rebuilds) the deadline for voicing a negative vote is basically by the time 3 votes are documented. But when time is not a factor, such as when requesting an exception to one of the criteria, then a period of one week will pass before being final, to allow times for concerns or negative votes to be voiced even after 3 positive votes. If there are not enough positive votes within one week, then the request for exception will be considered 'failed'. Note that "3" was chosen under the assumption that the Planning Council member representing the PMC would vote for it (since that PMC must approve it initially) so that means 2 others must also vote for it, for 3 total.
-
Depending on the timing, the issue and votes will be documented in either the Planning Council Meeting minutes, or on the Planning Council mailing list
. If possible, some automation may be added to the release reporting tool to aid this documentation
.
+
Depending on the timing, the issue and votes will be documented in either the Planning Council Meeting minutes, or on the Planning Council mailing list.
== Testing of Common Repository ==
== Testing of Common Repository ==