Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "WTP/Build/WTP Build Rhythm Schedule"

< WTP‎ | Build
(Friday)
(Finding That Sweet WTP Build Rhythm)
Line 1: Line 1:
= <i>Finding That Sweet WTP Build Rhythm</i> =
+
= <i>Finding That Sweet WTP Weekly Build Rhythm</i> =
  
 
The purpose of our weekly declared build is to make sure we have a build that mostly works, and is suitable to use as a target for for the following weeks development work. It is not for "end users" but may be used by some early testers to verify defects, get an early start on testing, etc.  
 
The purpose of our weekly declared build is to make sure we have a build that mostly works, and is suitable to use as a target for for the following weeks development work. It is not for "end users" but may be used by some early testers to verify defects, get an early start on testing, etc.  

Revision as of 11:53, 12 February 2009

Finding That Sweet WTP Weekly Build Rhythm

The purpose of our weekly declared build is to make sure we have a build that mostly works, and is suitable to use as a target for for the following weeks development work. It is not for "end users" but may be used by some early testers to verify defects, get an early start on testing, etc.

The quality of the weekly build can be expected to vary during a milestone cycle, just as milestones vary during a release cycle, but, of course, the quality should improve as we near a milestone.

Monday

  • Team development.

Tuesday

  • Team development.
  • Prerequisite dependencies finalized and in the builds. (This is the goal, but note anyone can request a dependency be updated at any time by posting to wtp-releng@eclipse.org.)

Wednesday

  • Team development

Thursday

-Teams should not commit any more changes until the build is declared. Unless, of course, it is to fix a bug that is literally blocking declaration of the build. Such bugs should be well documented in a bugzilla and announced to wtp-releng as a "respin request" (even though, the build will run automatically).
  • Team's smoke test and report status on wiki page by status meeting, 2 PM EST.
  • If a team needs to respin for a severe issue, the team may do so provided they report a failed smoke test status on the wiki and send a note to wtp-releng@eclipse.org with the defect number and explanation of which teams will need to re-smoke test the new build.
  • Discuss declaration of the weekly build during the WTP Status Call 2 PM EST.
  • In the event a re-build is required, then a new build will be complete by roughly 9 AM EST Friday.
  • For developers planning their work for the week, then, the above implies that 3 AM Thursday to 3 AM Friday (Eastern) should be "no release zones" ... where nothing routine is released, and only code that fixes a blocked build will be released. This insures a build is ready Thursday morning, and a possible respin by Friday morning. Hopefully, most weeks, this dead-zone will be shorter (i.e. build is declared early) and in some rare cases may be extended (e.g. we are getting close to a milestone and have had several weeks of no good build declared).

Friday

  • Team development.
  • Final declare or not-declare decision to be made by 3 PM Friday (Eastern time). If the weekly build is really bad, we may not declare that we have nothing to declare that week. In most cases, though, we will declare "with conditions" so potential consumers will know what to expect and they can decide if suitable for their needs.

Saturday

  • Team development.

Sunday

  • Team development.

Back to the top