Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "LTS/Requirements"
< LTS
(→Authorization and authentication) |
(→Build engine) |
||
| Line 53: | Line 53: | ||
* Builds must be isolated from the Internet - only pull software from Eclipse Foundation controlled sources like Orbit, Nexus, downloads. | * Builds must be isolated from the Internet - only pull software from Eclipse Foundation controlled sources like Orbit, Nexus, downloads. | ||
* Optional email notifications when the build starts and ends | * Optional email notifications when the build starts and ends | ||
| + | * Must keep permanent record of new content in any build | ||
==Prerequisites== | ==Prerequisites== | ||
Revision as of 14:56, 4 July 2012
Authorization and authentication
Limited access
- The LTS program shares code and artefacts to members only. The one exception is bugs. See the bug tracker section for more information.
Company specific forks
- LTS Premium and Steering Committee members enjoy rights to host their own company-private forks. Changes are kept private until after they are committed.
Notifications
- Optional email notifications when a new person is given access to a company specific forge
Code repository
Comparisons
A frequent administrative use case will be comparing content between releases of the code. This must be trivial to do and quickly reveal which bugs have been solved or not in each release. This input will be used for the change control committee to make prop recommendations which instruct maintenance integrators.
Off-line operation
- It must be possible to view history and queue changes without Internet access.
- It must be possible to prop changes between releases without Internet access (pushing changes after of course).
Notifications
- Optional notifications when a commit is made
Bug tracker
Privacy
- Must be able to keep a bug private to a given LTS member prior to release.
Publicity
- Once a bug has been fixed and distributed, the bug data should become public.
Bug Cloning
- Since a given bug may manifest in multiple releases, we require a master bug and a clone for each release that a fix is targeted. The master bug should depend on the children.
Meta data
- Must be able to track which release a given bug is meant for.
- Must be able to track whether a bug has been fixed for a given release both in the source and in the bug tracker.
Build
Build engine
- It must be possible to build without Internet access.
- Builds must be isolated from the Internet - only pull software from Eclipse Foundation controlled sources like Orbit, Nexus, downloads.
- Optional email notifications when the build starts and ends
- Must keep permanent record of new content in any build
Prerequisites
- Any tools or software required for the build must be version controlled in a managed repository
- Software required to test must also be version controlled in a managed repository
Build farm
Supported Platforms
The following platforms must be supported for building:
- Windows 32 bit
- Windows 64 bit
- Linux 32 bit
- Linux 64 bit
- MacOS 64 bit