Jump to: navigation, search

Difference between revisions of "LTS/LTS Ready"

< LTS
m (Build)
(Release Management)
 
(7 intermediate revisions by 3 users not shown)
Line 5: Line 5:
  
 
==Build==
 
==Build==
A build that
+
A build that builds on Eclipse Foundation hardware and
  
 
# Can be cloned/checked out with one step
 
# Can be cloned/checked out with one step
Line 17: Line 17:
 
## has maven 3.0.3
 
## has maven 3.0.3
 
## does it even need an eclipse SDK install?  If so, I'd suggest Indigo as a baseline
 
## does it even need an eclipse SDK install?  If so, I'd suggest Indigo as a baseline
 +
## does not depend on proprietary systems other than OS
 
# Can refer to compilers and other tools from a configurable location '''suggestion:'''
 
# Can refer to compilers and other tools from a configurable location '''suggestion:'''
## must be able to supply JRE locations for 1.4-1.7 Kim: We compile against the following libaries Foundation 1.0, Foundation 1.1, See the execution environment on a per bundle basis in the [http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_2.xml#appendix project plan].
+
## must be able to supply JRE locations for 1.4-1.7 We also compile against the following libraries Foundation 1.0, Foundation 1.1, OSGi Minimum 1.1, OSGi Minimum 1.2 See the execution environment on a per bundle basis in the [http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_2.xml#appendix project plan].
 
## to support the next requirement, must be able to supply local mirrors of required p2 repositories (orbit, indigo/juno, etc)
 
## to support the next requirement, must be able to supply local mirrors of required p2 repositories (orbit, indigo/juno, etc)
 
## signing at eclipse.org needs to be optional but configurable?
 
## signing at eclipse.org needs to be optional but configurable?
Line 25: Line 26:
 
# Capable of pulling dependencies from a known controlled source (e.g. Orbit, Maven, eclipse.org, etc.)
 
# Capable of pulling dependencies from a known controlled source (e.g. Orbit, Maven, eclipse.org, etc.)
 
# Adheres to Eclipse IP policies (esp. with regards to third party code)
 
# Adheres to Eclipse IP policies (esp. with regards to third party code)
 +
 +
==Testing==
 +
 +
A test suite that
 +
# Is version controlled
 +
# Is automated Andrew => is this so in all cases? can and should manual test cases be provided too?
 +
# Documented
  
 
==Bug Tracking==
 
==Bug Tracking==
 
* Bugs managed in Bugzilla, and possible to have appropriate meta data to manage and track bugs routed to each LTS release version
 
* Bugs managed in Bugzilla, and possible to have appropriate meta data to manage and track bugs routed to each LTS release version
 +
* It is clearly stated which bugs are in which release. Additionally, no code change can be released without proper bugzilla entry.
  
 
==Release Management==
 
==Release Management==
 
* Was released as part of the annual simultaneous release
 
* Was released as part of the annual simultaneous release
 +
OR
 +
* Was approved by a vote of the LTS Steering Committee
 +
 +
==Supply & Demand (for consideration)==
 +
 +
* At least two LTS IWG member companies offering support
 +
AND
 +
* At least two LTS IWG member companies seeking support

Latest revision as of 19:39, 11 October 2012

The following are the minimum required in order for a project to be considered Long Term Support (LTS) ready:

Code Repository

  • A distributed version control system capable of pushing branches from repository to repository. This repository should be one that is supported at the Eclipse Foundation. (e.g. Git)

Build

A build that builds on Eclipse Foundation hardware and

  1. Can be cloned/checked out with one step
  2. Is documented
  3. Is version controlled
  4. Is automated
  5. Is deterministic given the same source code and third party libraries
  6. Is easily reproducible on suitably-configured systems TODO: Can we define this a little better? suggestion:
    1. has git >=1.7
    2. has java >=6.0
    3. has maven 3.0.3
    4. does it even need an eclipse SDK install? If so, I'd suggest Indigo as a baseline
    5. does not depend on proprietary systems other than OS
  7. Can refer to compilers and other tools from a configurable location suggestion:
    1. must be able to supply JRE locations for 1.4-1.7 We also compile against the following libraries Foundation 1.0, Foundation 1.1, OSGi Minimum 1.1, OSGi Minimum 1.2 See the execution environment on a per bundle basis in the project plan.
    2. to support the next requirement, must be able to supply local mirrors of required p2 repositories (orbit, indigo/juno, etc)
    3. signing at eclipse.org needs to be optional but configurable?
  8. Capable of building without needing an active Internet connection question:
    1. does maven/tycho cache the bundles it needs from p2 repos in the local maven repo, so having run once you don't need your connection anymore?
  9. Capable of pulling dependencies from a known controlled source (e.g. Orbit, Maven, eclipse.org, etc.)
  10. Adheres to Eclipse IP policies (esp. with regards to third party code)

Testing

A test suite that

  1. Is version controlled
  2. Is automated Andrew => is this so in all cases? can and should manual test cases be provided too?
  3. Documented

Bug Tracking

  • Bugs managed in Bugzilla, and possible to have appropriate meta data to manage and track bugs routed to each LTS release version
  • It is clearly stated which bugs are in which release. Additionally, no code change can be released without proper bugzilla entry.

Release Management

  • Was released as part of the annual simultaneous release

OR

  • Was approved by a vote of the LTS Steering Committee

Supply & Demand (for consideration)

  • At least two LTS IWG member companies offering support

AND

  • At least two LTS IWG member companies seeking support