Jump to: navigation, search

Difference between revisions of "Developer Team Page"

m (Meetings and Events)
(SVN Branch Structure)
Line 11: Line 11:
 
Misc:
 
Misc:
 
* [[Higgins F2F planning]]
 
* [[Higgins F2F planning]]
 +
 +
== Bugzilla ==
 +
* Bugs, features, etc. for each component are tracked in Bugzilla
 +
* To see all bugs [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Higgins&query_based_on=%20open open], [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&product=Higgins&query_based_on=%20closed closed]
 +
* To see the open, closed bugs for each component see [[Components]] page
  
 
== SVN Branch Structure ==
 
== SVN Branch Structure ==

Revision as of 10:15, 29 October 2008

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

This page is information for active committers and contributors.

Meetings and Events

Upcoming:

Past:

Misc:

Bugzilla

  • Bugs, features, etc. for each component are tracked in Bugzilla
  • To see all bugs open, closed
  • To see the open, closed bugs for each component see Components page

SVN Branch Structure

Version Numbering

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.
Features
We only have one feature and we follow the rules in Version Numbering.
Components
in Higgins are sets of related projects. But they are just organizing concepts and not digital artifacts. We have not found a need to have version numbers for components. So there is no problem here.
Solutions
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.
Higgins
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.

Backlog

The list of all kinds of things that we might like to do someday:

Processes

  • Higgins Development Processes
  • How to sign up for daily build pass/fail email notifications:
    1. 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.
    2. 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:

<buildProject id="org.eclipse.higgins.idas.cp.jena2">

 <pathFromWebHome>downloads/idas.cp.jena2</pathFromWebHome>
 <successMailList>slyakhov@aquasoft.dp.ua</successMailList>

<failMailList>slyakhov@aquasoft.dp.ua,jimse@novell.com</failMailList>

      <targetToRun>plugin</targetToRun>
      <targetToRun>jar</targetToRun>
      <targetToRun>javadoc</targetToRun>

</buildProject>"

  • 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.

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:

  1. Bugs in any of the Higgins platform components that cause a crash of the overall Higgins system or Higgins based application.
  2. Bugs that cause a loss of any persistent data.
  3. Bugs that cause a severe security breach where sensitive end user data can be exposed to the outside world or accessed by unauthorized users.
  4. Bugs that cause a "major" feature to not function and there is no workaround available to accomplish the same task.
  5. 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:

  1. Ensure that a bugzilla ticket has been created for the issue outline the details of the bug in the ticket.
  2. Review the nature of their bug against the above outlined criteria
  3. 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.
  4. 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.
  5. 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.

Documentation

Component Owners MUST:

  1. Create rows (and sometimes entire tables) for each project on the Components page.
  2. Manually create (and constantly update) the "dep" wiki page in the "Dependencies" column (entitled "Dep.") for each project/row on the Components page.
  3. Edit the autobuild scripts to include java components in the nightly build
  4. Create a "row" wiki page for each row using the Component Description Template
  5. Make sure that automated build scripts are using the latest build.xml
  6. Make sure that all 3rd party dependent jars are read from the dependencies.redistributable project. For projects that autobuild this can be verified by checking that the auto-generated "Third Party Dependencies" section of the "dependencies" page linked from a build page (see the "downloads" column on the Components page.

Solution Owners MUST:

  1. Add a link to the solution here Solutions
  2. Create the solution page using Solution Description Template

Anyone editing the wiki MUST:

  1. Put the string {{#eclipseproject:technology.higgins}} at the top of all pages. [This adds the correct Higgins left-hand navigation links to the page]
  2. Put the mouse on new pages by inserting the string [[Image:Higgins_logo_76Wx100H.jpg|right]] at the top of the page.
  3. Version wiki pages (adding a "Version" section at the top) as needed (see below).
  4. Categorize the page by including the category at the bottom of the page. See [1] for a list of all Higgins Categories. For example insert [[Category:Higgins]] for general Higgins info. (Yes, the categories could use some maintenance.). Or insert [[Category:Higgins Data Model]]

Versioned Wiki Pages

We have worked out a convention for dealing with versioning in wiki pages. For any wiki page that needs versioning, there should exist a wiki page name that does NOT include a trailing version number (e.g. http://wiki.eclipse.org/Context_Data_Model). This un-versioned page should use the #REDIRECT command to redirect to a versioned page (e.g. http://wiki.eclipse.org/Context_Data_Model_1.0) that includes in its URL a version suffix (e.g. “1.0”) taken from the most recent released version of Higgins (i.e. the “1.0” in “Higgins 1.0”). Lastly, at the top of every page, there should be a “Version X.X” section (see, for example the top of http://wiki.eclipse.org/Context_Data_Model_1.1) preferably containing links to the other versions of the page.

To minimize work, create multiple versions of a wiki page only when absolutely necessary, and to reuse and link to any (unversioned) pages and sub-pages where ever possible. Unversioned wiki pages don't have to have a "Version" section at the top.

Examples:

If you need to version a page that hasn't been versioned before:

  1. Create TWO new pages that are copies of the original page. Edit each copy to describe the applicable version.
  2. Add a version section at the top of each of the two new pages as shown in the examples above.
  3. After you have created these new pages, change the original unversioned page such that it contains nothing but a #REDIRECT [[<page name>]] (where <page name> is the name of the page that describes the released version of Higgins.

Technical References

Developing

Java projects:

  1. Must be developed using Eclipse 3.3
  2. Must follow Project Structure and Naming
  3. Must follow Project Dependencies
  4. Must use Higgins2Ant
  5. 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

In general

  1. All files must carry correct headers, copyrights, license. See: Higgins File Headers
  2. Internationalization: The proposal for Higgins Globalization can be found on the Internationalization Support page. All components and solutions must support internationalization. The goal is to have Higgins 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.

Building

Deploying

Test Automation

  • 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:
      1. Identify/develop autotest capbilty on top of our existing Higgins centric ANT based autobuild platform OR
      2. 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...]

Misc Tools

IP-Related

Contributions by team members

Eclipse Foundation-related Info

Eclipse Committers

IPZilla

Legal

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

  • 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.

Marketing