helios train requirements
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
|
 
Still loading...
ABCDEFG
1
Helios Train Requirements
2
CategoryItemStatusTimeframeMaster
Bug
Sequoyah
Bug
Comments / Actions
3
Do the basics ... EarlyProjects must have stated their intent to do sook
4
Be in a build for the composite site aggregation by M4okM4BUILD
[MG-10.02.10]
- Build ok: P2 repo; signing; build script done
- Release bugs: waiting for David's answer about if we should open bugs for helios train requirements
- Graduation: we are going to graduate in Helios train release. We need to schedule a Graduation review meeting along the Release Review, and we need also to prepare the slides - Eric will ask to Anne in order to request our meeting
- We won't use Buckminster for now
[MG-10.02.12] It seems that we will need to follow the release process manually for now.
[MG-10.02.22] Testing our build script in Helios environment - some adjustments are necessary
[MG-10.02.26] We identified the compilation problem and trying to fix it (we still need to test it against Galileo and Helios)
[MG-10.03.04] Build process being updated to incorporate MTJ / Pulsar components
[MG-10.03.12] Starting to integrate our build to Helios build process.
[MG-10.03.19] Build integrated and working fine. From now on, we just need to maintain it, and add minor changes when necessary.
[DP-10.04.05] Same status.
5
Be in a build for the composite site aggregation by M4okM4EPP and Pulsar
[MG-10.02.10]
- We will migrate Pulsar and MTJ components (branding, perspective, SDK discovery and Pulsar feature) to Sequoyah
- We need to select which TmL inherited components will be in Pulsar package
- We need to change Pulsar package (feature.xml) in order to reflect both points above
- We need to decide what will be the migration strategy
- Packages should usually only contain code from projects that have
passed their 1.0 creation review, and if exceptions are found, the code must still have passed an Eclipse Release Review
[MG-10.02.12]
- Migration strategy: remove from MTJ repo, update scripts and send a message in MTJ/Pulsar mailing list
- TmL components to be added to Pulsar: put all TmL pieces we actually use (Studio dependencies)
[MG-10.02.22] MTJ/Pulsar components migration started. We need to rename such components and also update Pulsar package. However, this item should not be a requirement for Helios train
[MG-10.02.26] Matt copied MTJ/Pulsar components to Sequoyah repo. We need to start working on renaming and after that, updating Pulsar package. We still need to see the effort necessary for this task.
[MG-10.03.04] MTJ/PulsarComponents migration almost done. We still need to fix SDK discovery component.
[MG-10.03.12] SDK Discovery component fixed using P2 only. We still need to update Pulsar package generation. Pulsar package will contain:
- Sequoyah code, including TmL and Pulsar SDK Discovery
- MTJ project
- signing component from MTJ is present neither in MTJ nor Pulsar
[Action-MG/DP] We need to decide what will be Pulsar versioning - discuss this point in the next tech meeting.
[MG-10.03.19] Pulsar package updated with Sequoyah content and working fine. Previous Pulsar versioning schema maintained. From now on, we just need to maintain it, and add minor changes when necessary.
[DP-10.04.05] Same status.
6
PlanningAll projects must have their project plan in the Eclipse Foundation standard XML Format ongoingM4Waiting for a better definition of the project roadmap
- work on this after having the build done (no impacts)
[MG-10.02.12] started a draft version, we need to validate the xml before submit it. Plan: finish it in the next 2 weeks.
[MG-10.02.22] draft version sent to Eric on Feb/19. We need to rework the content of this file and after that we need to adapt to XML format.
[MG-10.02.26] Porting to XML format ongoing
[MG-10.03.04] First version done and integrated in the website.
[DP-10.04.05] Same status.
7
Commitment to participating the SR1 and SR2 simultaneous maintenance releasesokThere is nothing to do here right now
8
CommunicationAt least one person from each project in a Simultaneous Release must subscribe to cross-project mailing listok
9
At least one person from each project must subscribe to cross-project bugzilla inboxok[Action-MG/DP]we need to check how to do this
[DP-10.02.01] Marcel sent an email to Eric, because he has to forward us any email he thinks we should know about.
[MG-10.02.12] Eric will redirect the emails to us
10
Your representative to the Planning Council, either from PMC or Strategic Member, must attend PC meetings and represent you thereokMartin and Eric will represent DSDP
[MG-10.03.08] This point might change based on PMC resolution in the next meeting.
11
IP DocumentationProjects must have their IP Logs approved. The ones for M5 and M6 will be understood to be "drafts" but for most projects the IP Logs should be relatively complete by M7ongoingM5, M6, M7[Action-MG/DP] On bug 289870 it was said that all CQs from TmL were moved to Sequoyah. Need to check if TmL 0.4 IPLog is still valid or if is it necessary to change it to Sequoyah, since we integrated Localization.
- we need to go to the portal and update IP Logs from TmL 0.4 to Sequoyah 0.5 (for M5 we'll use TmL 0.4)
[MG-10.02.04] Email sent with new spreadsheet. We believe we don't need to submit any CQ for now, but we need to double check this point.
[MG-10.02.10] Send an email to Sharon and Barb in order to have an agreement that what we have so far was once reviewed and it is ok, and that we would need CQs only for new features. MTJ components added in this subject.
[MG-10.02.22] Email sent to Sharon, bug updated - we only need to move one CQ - ongoing
[MG-10.03.12] Sharon moved CQ.
[Action-MG] we need to update IP log spreadsheet in order to include new bugs opened in Sequoyah.
[MG-10.03.19] Same status.
[DP-10.04.01] IP Log updated.
[DP-10.04.05] Committer's names confirmed.
[DP-10.04.06] As suggested by Sharon Corbett, we're changing our IPLog spreadsheet to the automated model, using Eclipse.org (setting the flags on the bugs).
12
Release ReviewThe release review archival materials must be complete by the date specified by the EMO, which is usually staged in earlier than for a usual release. (Typically RC2.)openRC2[Action-Eric] We need to check with Eric if it is possible to reuse release review from TmL 0.4 or if we need a new one for Sequoyah once the project scope is defined.
- it is better to get a new one (mid April)
13
A PMC must provide their approval in writing, in the form of a short summary of their projects that are requesting review and summary of the PMC's discussion open
14
The public review calls will be organized based on Top Level Project, and at least one PMC member should be on that call to give very brief overview of projects that are requesting the release review (not to exceed 5 minutes, at the very most)ongoing[MG-10.03.12] We need to start planning our Release+Graduation Review meeting. - We need to prepare our slide deck, after EclipseCon.
[Action-MG] Start working in our slide deck
[MG-10.03.19] Same status.
[DP-10.04.05] Same status (we should have a draft version by 04.19).
15
In addition to the ordinarily required Release Review Archival Materials, all Projects participating in yearly Release agree to provide a checklist-with-detail form that describes their compliance (or not) with all of the criteria items described in this documentongoingAssuming this list/spreadsheet can be used for this purpose
[DP-10.02.01] We have to publish it on Sequoyah's wiki later. Can't use GDocs web page publishing.
[MG-10.02.04] Check with Eric if Marcel can do this (to publish on wiki - not sure because Marcel is not a committer yet - BTW, discuss committer status: 2 contributions made so far)
-- 3 contributions and request committer account
[MG-10.02.10] Publishing this spreadsheet in our wiki should be enough for this requirement.
[MG-10.02.12] We need to check bugs related to release train (depends on the answer to Eric's email to Anne Jacko and Wayne)
- It seems that we will need to follow the release process manually for now.
[MG-10.03.19] There is a release tracking area in the portal, we are already updating it.
[DP-10.04.05] Same status.
16
Play well with others ... to be in common repositoryCommunication: Build team members (or their designated alternates) from each project may be asked to provide direct communication channels: phone, mail, IM, IRC and at least one build team member must be "on call" during the milestone integration periodsok
17
API. Projects should leverage only published APIs of dependencies. All deviations must be documented in bugzillas.ongoing[Action Mg/DP] We need to check this regarding TmL->Sequoyah migration and also MTJ components integration.
[MG-10.03.12] We need to open bugs due the use of internal P2 APIs in SDK Discovery component.
[Action-MG/DP] open bugs
[MG-10.03.19] Same status
[DP-10.04.01] Bug opened (https://bugs.eclipse.org/bugs/show_bug.cgi?id=307883) and updated on simultaneous release tracker.
18
Message Bundles. Projects must use Eclipse message bundles unless there are technical reasons not took
19
Version Numbering. Projects must use 4-part version numbers.okFormat being used: 0.5.0.<buildType><timestamp>
20
OSGi bundle format. All plug-ins (bundles) must use the true bundle formok
21
Execution Environment. All plug-ins must correctly list their Bundle Required Execution Environment (BREE)okTalk to GregW/Brent in order to create new help plugins updated with Sequoyah information
[MG-10.02.10] Email sent, GregW and Brent aligned
22
Signing. Projects must use signed plugins using the Eclipse certificateokThis task is related to build generation / buckminster integration
[DP-10.02.04] WIP, should be concluded today
[MG-10.02.05] DP finished this step
23
Jarred Bundles. Projects must use jarred plug-ins (with unpack=false) unless authorized by the planning council for technical exceptions. Also, nested jars should be avoided if possible since it creates problems for projects that has dependencies to such plug-insok
24
Re-use and share common third party jars. Any third-party plug-ins that are common between projects must be consumed via Orbitok
25
Optimization. Projects must optimize their p2 repositories to reduce bandwidth utilization and provide a better install and update experience for usersok
26
Provide p2 repository. Projects must provide their own project p2 repository for their own project and updates. In addition, they must provide their archives and metadata in a specified format and method to allow at least parts of their repository to be aggregated and mirrored to a common repositoryokThis task is related to build generation / buckminster integration
[DP-10.02.04] The files can be copied to and update site during build process
[MG-10.02.05] DP finished this step
27
Capabilities. Each project will provide basic capability/activity definitions to allow for their UI contributions to be hiddenok
28
Support Translations. All strings must be externalized, and Projects must participate in Babel, meaning it is registered and available for string translation, etc.ongoingThis task is related to build generation
- check what is the timeframe and submit what we have right now
[MG-10.02.10] We submitted a bug to Babel project so an entry to Sequoyah can be created in their site.
[MG-10.02.12] Kit created a jar, but based on TmL update site, and not our map. We contacted Kit.
[MG-10.02.22] Some items must be externalized. Ongoing.
[MG-10.03.12] We performed the necessary fixes. We need to test it again using PTT.
- We need to check code migrated from Pulsar.
[Action-MG/DP] Execute tests / Check code migrated from Pulsar.
[DP-10.03.30] Talking with Babel team to decide if we create a map for Pulsar or if we append Pulsar packages on Sequoyah's map. Either one still needs to be tested.
[DP-10.04.05] Still waiting Babel team.
29
Excel in NL support. The Project must use ICU4J, where appropriate, to excel in NL support. (The latest ICU4J bundles will be in Orbit).okTry to find out if this is mandatory or not
[MG-10.02.08] According to EclipseSimultaneousRelease document, it seems to be mandatory to use this component. However, according to:
- ICU4J home page (http://wiki.eclipse.org/ICU4J), a project shouldn't use ICU4J unless it is really required
- TmL Galileo checklist (http://wiki.eclipse.org/Galileo_Simultaneous_Release#Requirements_For_Participation) and bug 257303 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=257303) TmL / Sequoyah is already using this component.

Conclusion: We should use this component if necessary (time and date formats, etc). For now, we don't believe it is necessary to use it.
Nice to have, let's just document this decision in our bugs
30
Branding. Each major project (as determined by participating PMCs) must have an 'About' dialog icon with hover text that displays the provider name. Every plug-in and feature must specify a descriptive provider-name (for features), or Bundle-Vendor header (for plug-ins), as determined by the project's PMC (e.g. "Eclipse Modeling Project" rather than "Eclipse.org"). Also, Projects must contribute to the welcome page when appropriateokThis task is related to the currently ongoing branding task.
[DP-10.02.01] The branding is finished on /branches/branding. Testing modifications before merging back to trunk.
[MG-10.02.10] Changes merged to trunk. Everything is working fine.
[MG-10.02.10] Check with Eric DSDP branding
[MG-10.02.12] According to Eric, it won't change right now.
31
Do No Harm. Projects must work together in any combination of any installok
32
License text consistency. Use standard forms of license documents so it is displayed in the most usable, and concise way during install and updateok
33
Be a good Eclipse Citizen ... and document itEngage Community. The Project should actively engage their community to get feedback on milestone builds, and document how they do that. One way to do this is to have a New & Noteworthy for each milestoneongoingKeep notes as we go along. It should be good to have one per release. (not for each milestone)
[MG-10.02.22] We already are using more our mailing lists. Also, we are updating our wiki and web site pages.
[MG-10.2.26] We need to plan the website structure. We are going to elaborate a proposal and then present it to Eric next week.
[MG-10.03.04] Plan for new web site structure presented to Eric. We'll evolve the site according to this plan.
[MG-10.03.12] Website development on hold this week. Build activities priority increased.
[MG-10.03.19] Website and wiki being updated.
[DP-10.03.30] Same status. Trying to make a new automated downloads/RSS model (low priority).
[DP-10.04.05] Updated some project news. Still working on automation.
34
Usability. Should follow the User Interface Guidelines. The UI Checklist is a good place to start. Also, should participate in a User Interface Best Practices Working Group UI walkthrough.ok
35
Performance. Project should have measurable performance criteria that are regularly tested against. Projects should devote at least one milestone to performance and scalability improvementsopenNice to have, leave it open for now
36
Test Localization. The project should use the Babel Pseudo Translation Test to verify their translatabilityongoing[MG-10.03.12] Tests ongoing
[MG-10.03.19] Same status
[DP-10.03.30] Sequoyah needs some tweaks on its externalized strings, according to the latest PTT ran.
[DP-10.04.05] Same status.
37
Enable Use with All Languages. Should design and test for enabling all languages including bidi, unicode characters, etcopenVerify if we are still ok, and check Pulsar pieces.
38
Builds. Projects must have a mature, stable build process: documented, scripted, repeatable, and executable by othersokRelated to our new build generation task
[MG-10.02.10] We have a regular build now.
[MG-10.02.22] Adjusting to Helios build environment
[MG-10.03.04] Components migration almost done. We still need to fix SDK discovery component.
[MG-10.03.12] Starting to integrate our build to Helios build process.
[MG-10.03.19] Build updated and working fine.
39
Ramp Down Planned and Defined. Projects must have a written ramp down policy by M6, at the latest, and provide link.ongoingM6[MG-10.02.22] Ramp down policy draft stated in the Project Plan. It refers to TmL and MTJ policies.
[MG-10.02.22] We consider this item ok for now. We'll update the Ramp Down Policy once we have the release train ok.
[DP/DF-10.03.30] Starting to work on this.
[DP-10.04.05] Same status (follow TmL 0.4 model).
40
Accessibility. Projects should design and test for accessibility compliance, following established guidelines and Eclipse fundamental techniques to achieve accessibility. ok
41
Unit Tests. Projects must have some unit tests that can verify at least basic functionality of a build or distribution. The steps to build and run the tests must be documented and executable by othersongoingPriority between now and M6, at least few tests
[MG-10.03.12] We didn't have time to explore this item until now. Is it possible to implement some cases after M6?
[MG-10.03.19] Ongoing. We started to work in a Test Plan.
[DP-10.03.30] Still working on the Test Plan and Unit Tests.
[DP-10.04.05] Same status (check on cross-dev if it should be automated, maybe for SR).
42
API Policy Defined and Documented. Typically would include how 'APIs' are distinguished from non-API and 'provisional' API, if any. It is recommended that non-API be marked with x-internal in the bundles manifest. Also, should include what the commitment is to API, how long maintained after deprecated, etc. As one example, see WTP API Policy.ongoing[DP-10.04.05] Our APIs are defined on Sequoyah. APIs on Pulsar may change according to the SDK Discovery fix. Still needs to document.
[DP-10.04.06] SDK Discovery fix probably won't change Pulsar APIs, according to David Dubrow.
43
Retention Policy. Projects should define and document their retention policy. This should include both zip distributions and repositoriesokAsk what is Christian's opinion about this point.
[MG-10.02.22] Christian suggestion:
- keep releases and milestones builds and all the nightlies since the last milestone.
- A specific nightly might be kept if a product depends on it. If this is the case, contact the team in order to warn them that you depends on this build.
- Keep a document listing which build was used in a specific product.
- Document this policy in the download page
[MG-10.03.19] We documented our Retention Policy in the Website, wiki and download pages.
44
Project Metrics. 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.openCheck what is the best place to put this information
45
Incubation Requirements
46
Development Resources/HOWTO/Conforming Incubation BrandingIs in the Incubation phaseok
47
Correctly displays the incubation logo on their project home pageok
48
Correctly displays the same incubation logo on their project's primary download pageokFlag in the project metadata
[DP-10.02.01] There's no flag in project metadata. We need to change the download page's HTML code.
[DP-10.02.01] Download page ok.
49
All downloadable zip files for builds and milestones must include the word "incubation" in the filename. For example, DSF-SDK-incubation-N20070413-0200.zipokThis task is related to build generation / buckminster integration
[MG-10.02.04] ok, but we need to check how and when we can change our status to a regular incubation project.
[MG-10.02.10] We won't change our incubation status right now. It's better to change everything when we graduate.
50
All "Bundle-Name"s must include the world "incubation". Note that "Bundle-SymbolicName"s should not include "incubation" because the Bundle-SymbolicName is a technical namespace, not a user namespace. For example, Bundle-Name: Foo Plug-in (Incubation)okThis task is related to build generation / buckminster integration
[MG-10.02.04] ok, but we need to check how and when we can change our status to a regular incubation project.
[MG-10.02.10] We won't change our incubation status right now. It's better to change everything when we graduate.
51
Similarly, the names for update manager features must include the word "incubation". For example, Eclipse Platform (Incubation)okThis task is related to build generation / buckminster integration
[MG-10.02.04] ok, but we need to check how and when we can change our status to a regular incubation project.
[MG-10.02.10] We won't change our incubation status right now. It's better to change everything when we graduate.
Loading...
 
 
 
Sheet1
Sheet2
Sheet3