Difference between revisions of "Developer Team Page"
|Line 72:||Line 72:|
* Adding your name to both lists will include you in daily status emails whether the component passes or fails.
* Adding your name to both lists will include you in daily status emails whether the component passes or fails.
Revision as of 10:47, 30 July 2009
This page is information for active committers and contributors.
- 1 Meetings and Events
- 2 Planning
- 3 Bugzilla
- 4 Source Code
- 5 Processes
- 6 Building
- 7 Deploying
- 8 Test Automation
- 9 Higgins Bug-Fix Release Criteria
- 10 Technical References
- 11 Misc Tools
- 12 IP-Related
- 13 Contributions by team members
- 14 Eclipse Foundation-related Info
Meetings and Events
- Mary talks at EclipseCon 2009: talk
- Oct 27-29 2008 - Boston F2F
- May 20-21 Seattle F2F Agenda
- Higgins Past Meetings and Events
- Click on "Project Plan" at left hand menu
- Bugs, features, etc. for each component are tracked in Eclipsezilla (Bugzilla)
- All bugs: open, closed
- To see the open, closed bugs for each component see Components pages
- MUST be developed using Eclipse 3.3
- MUST follow Project Structure and Naming
- MUST follow Project Dependencies
- MUST use Higgins2Ant
- In general it MUST build using JRE 1.4 (and must support both Sun and IBM JREs). To ensure this, projects must set compiler compliance level to 1.4. The Higgins project team may decide to make exceptions for specific components for Higgins 1.1 to use JRE 5.0 (1.5)
- All files must carry correct headers, copyrights, license. See Higgins File Headers
- All projects MUST support internationalization. See Internationalization Support
- The goal is to have Higgins 1.1 code internationalized, such that other users could localize the code to their native deployment requirements. Some specific elements of this would include:
- Static strings must be stored in external resource bundles that can be called at runtime. These resource bundles can then be the focal point for localization.
- We can leverage the Babel project/tools in Eclipse found here. This tool can be used to help in doing translations.
- There are also some Eclipse plug-in internationalization 'how to' instructions for development and testing located here.
There are four levels of granularity in the Higgins project:
- SVN Projects
- are named major.minor.service.qualifier as described in the "plugins" section here: Version Numbering. [For java projects every project is indeed a plugin. But for non-java projects a project might be a C++ lib, etc.] For projects (plugins) we are following the rules in Version Numbering.
- We only have one feature and we follow the rules in Version Numbering.
- a set of Components. They are organizing concepts, not digital artifacts. We have not found a need to have version numbers for components.
- in Higgins are sets of one or more related project-folders. They are just organizing concepts and not digital artifacts. We have not found a need to have version numbers for components.
- in Higgins are complete working apps or web services. There is no equivalent concept in Version Numbering. We do not use version numbers at the solution level.
- is the name for the entire project. This is roughly equivalent to numbering of the entire Eclipse IDE (e.g. Eclipse 3.1 or 3.2).
- The first bugfix release after 1.0.0 will be 1.0.1 (see Beyond Higgins 1.0)
- The first milestone (stable build) after 1.0.0 will be 1.1M1 (see Beyond Higgins 1.0)
- We expect to have Higgins 1.1 stable builds approx every 6 weeks or so.
- Higgins Development Processes
- How to sign up for daily build pass/fail email notifications:
- Modify the the successMailList or failMailList in the projects.xml file in org.eclipse.higgins.auto.resources project located at trunk/builds folder in SVN.
- These fields will contain comma separated email lists. Anyone can add their name to any component and either pass list, fail list or both if they desire.
- The following is an example:
<targetToRun>plugin</targetToRun> <targetToRun>jar</targetToRun> <targetToRun>javadoc</targetToRun>
- Adding your name to the successMailList will then include you on daily emails if all component targets passed the daily build.
- Adding your name to the failMailList will then include you on daily emails if all component targets failed the daily build.
- Adding your name to both lists will include you in daily status emails whether the component passes or fails.
- Automated Builds --description of the existing nightly build process (see Build Enhancements for a wishlist of enhancements to the nightly and developer build processes)
- Starting a Higgins Build --how to kick off a build on the eclipse build server
- Copying necessary 3rd party libs to project lib folder using PERL script --steps to copy all necessary 3rd party libs from centralized location (local) to project lib folder
- Deployment Requirements -- gathering requirements for our build/deploy processes
- Component and Integration Test Automation:
- A sub-team has been meeting to assess what auto-test tool could be adopted by Higgins project to support automated component level and solution level integration testing that can be run after the auto build process.
- The baseline assumption is the auto-test solution Higgins choses would need to build on top of the auto-build platform. The two basic auto-test (and build platform) options would include either:
- Identify/develop autotest capbilty on top of our existing Higgins centric ANT based autobuild platform OR
- Extend Buckminster autobuild capability and migrate Higgins components to this new build platform over time. The follow on would be to leverage this same platform (with collaboration from wider Buckminster team) to develop integrated auto-test capability over time.
- To support the scoping of option (2) above, we (Mike M from IBM) is working on determining the extensions needed to the the current Buckminster build capability to support the current STS autobuild needs. Mike is currently investigating this.
- Observations on IdAS test automation (David Kuehr-Mclaren - IBM)
- [to be filled in...]
Higgins Bug-Fix Release Criteria
Higgins patch releases (e.g. 1.0.X number scheme) would include exclusively bug fixes (e.g. no new features/enhancements) for the following type of bug severity:
- Bugs in any of the Higgins platform components that cause a crash of the overall Higgins system or Higgins based application.
- Bugs that cause a loss of any persistent data.
- Bugs that cause a severe security breach where sensitive end user data can be exposed to the outside world or accessed by unauthorized users.
- Bugs that cause a "major" feature to not function and there is no workaround available to accomplish the same task.
- Bugs that cause a "major" business impact such as loss of revenue or customers.
For all other bugs fixes of lesser severity than those described above, they will be included as part of major or minor (point) Higgins releases and not necessarily included as part of a special bug fix release. By way of example, the bug fixes included in the major or minor (point) releases would include such items as:
- bugs that cause an aspect of a feature to not work properly.
- bugs are that are cosmetic in nature, misspellings in dialogs, annoying to users, etc.
The following are the process guidelines Higgins team members should follow to support bug-fix releases:
- Ensure that a bugzilla ticket has been created for the issue outline the details of the bug in the ticket.
- Review the nature of their bug against the above outlined criteria
- If you feel the bug matches the criteria to be included in a future bug-fix release, send an email to Higgins-Dev and address request to Brian Walker to include this in an upcoming bug-fix release. Please note in the email whether the bug has been fixed already, or requires the component owner to work on creating the fix.
- If you have already made the code fix and you are not the component owner, all you need to do is submit the code fix to the appropriate component owner and request they commit the code fix.
- Most Important - when the code fix is committed, please make sure that the code is committed to the head branch, as well as the B-1-0-0 code branch as well. The patch release will be completed off the B-1-0-0 code branch.
- Higgins Specs --how to generate HTML spex from XML input files
- Generating anonymous psf file using PERL script --steps to generate anonymous psf file for a project including all it's dependencies
- List of Higgins 1.0 Third Party Dependencies --status of each dependency as set by the Eclipse Legal team
- List of Higgins Third Party Dependencies --status of each dependency as set by the Eclipse Legal team (This was the original list and has some more cross reference info than is part of the official list above, so we're keeping it around.)
- Higgins 1.0 IP Log
- Higgins IP log
- Open Higgins Ipzilla items (committers only)
- Response to Open Specification Promise --Higgins and Microsoft CardsSpace
- Draft Response to Open Specification Promise --earlier draft
Contributions by team members
- Higgins committers with contributions active in the 1.0 repository --Eclipse Legal Review
- Higgins developers with contributions active in the 1.0 repository --Eclipse Legal Review
- Higgins commiters by component
- Development Resources
- Eclipse Development Process 2006 Revision Final
- Guide to the Eclipse Legal Documents
- Eclipse Committer Due Diligence Guidelines, feel free to email firstname.lastname@example.org with any IP related licensing or process questions
- Eclipse Legal Copyright standards
Clarification of IP processes for use of third party libraries
- Any time anyone working on the Higgins project wants to introduce a project dependency, it needs to be brought forward to the Higgins project.
- If the decision is made to introduce the dependency and the dependency involves software that is not licensed under the EPL, then a formal IP process needs to be gone though to approve the software binaries for inclusion in the project cvs. Note that this process must be followed even if the software is a common java library used by other Eclipse processes. (If the software has been used by another Eclipse project, the process is much faster.) Eclipse has a system IPzilla for managing this process. If you are anticipating a dependency, you need to bring it forward as soon as possible to allow time for the IP due diligence process to take place. See more about IPzilla below.
- Libraries licensed with EPL are the easiest to get permission to use, followed by Apache 2.0. GPL and LGPL licences are not compatible with EPL.
- Orbit http://www.eclipse.org/orbit/ is designed to be a repository for third party libraries that are approved for use in Eclipse projects. If the incoming libraries are not already bundles then Orbit committers will work to create a bundle that is suitable for use in Eclipse projects. See http://wiki.eclipse.org/index.php/Orbit_Faq for a list or Orbit managed libraries. Orbit managed libaries are the easiest of third party libraries to add to an Eclipse project. Even if a library is listed under Orbit, you still need to go through the IPzilla process before putting it into the Higgins CVS.