Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] Planning Meeting Notes - May 14, 2003 (Eclipse committers please read)


We have decided to make some minor changes in our build story in order to better focus the responsibility for getting good integration builds on the developers:

For the 3.0 integration builds:
- build time is 8:00am (Eastern time) on Tuesday mornings (as it is currently).
- in the event of an integration build failure, there will be a rebuild at
  8:00am Wednesday morning.
- in the event of a double integration build failure, all other work will stop until
  guaranteed-to-be-succesful build contributions are prepared for a rebuild at
  8:00am Thursday morning.
- once a good integration build is achieved, it will be marked as such on the website.

For the 2.1.x integration builds:
- build time is moved to 11:59am (Eastern time) to ensure that they do not
  conflict with any (potential) 3.0 rebuilds.
- because of the nature of the fixes in this stream, these builds should not fail.
  However, if a rebuild is requested by one of the teams, it will take place as soon
  as the build contribution is available.
- once a good integration build is achieved, it will be marked as such on the website.

In the above descriptions, a build is considered to be a failure if there are "Red X"s that the developers agree represent valid reasons for them to not begin using the integration build. An example of a Red X which would *not* require a re-build would be a test which failed because the test was bogus.

IMPORTANT: This strategy _requires_ us to have good build inputs. All teams must use the tools to pre-build and test their submissions. In addition, teams should track the nightly builds to detect integration problems early on. What we want to achieve is for the Tuesday morning 3.0 build to typically be successful, with an infrequent requirement for a Wednesday morning build. Failing the Wednesday morning rebuild should be treated as a catastrophic failure. In other words, more than two or three of these per year is an unacceptable failure rate.


STATUS
======

JDT UI:
- posted component and milestone plan
- 2.1.1 fixes
- new set of quick fixes related to parameter mismatches in method invocations
- started investigation on refactoring participants for rename refactorings
- started on the rewrite of the (non refactoring) code reorganisation operations


Debug:
- Investigating API for a more general/shared console
- Continued development on "in-line" object browsers in variables view

Ant:
- Ant editor content assist now provides required attributes for tasks
- Working on socket communication for Ant in seperate VM (to provide proper
  console coloring/hyperlinks)


Platform/JDT Text:
- component and milestone plan posted
- improved smart typing
  - released Smart Enter, Change Case, and Move Lines
  - continued working on Smart Semicolon
- continued investigation of improved information presentation
  - user can choose whether information should be shown in a hover or in a view part
  - information can be presented in any kind of form: text, lists, trees, etc.
- extensive discussions with major client

Core:
- plan on putting the fix for bug 36373 in the 2.1.1 maintenance stream
- have integrated the new PDE/Build mechanism code into the main repository on
  dev.eclipse.org
- work continues on dynamic plug-ins and concurrency

Back to the top