Skip to main content

Notice: This Wiki is now read only and edits are no longer 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 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 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 ==
 
== Monday ==
Line 17: Line 20:
 
== Thursday ==
 
== Thursday ==
  
*Weekly candidate build produced (roughly 9 am EST, at the LATEST) and [[WTP Smoke Test Results | smoke test wiki page]] created.
+
*Weekly candidate build produced (roughly 9 am EST, at the latest) and [[WTP Smoke Test Results | smoke test wiki page]] created.
:-Teams should not commit <b><i>any</i></b> more changes until the build is declared. Unless, of course, it is to fix a bug that is 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).  
+
:-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 [[WTP Smoke Test Results |wiki page]] by status meeting, 2 PM EST.
  
*Team's smoke test and report status on [[WTP Smoke Test Results |wiki page]] by 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 [[WTP Smoke Test Results | 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.
 
*If a team needs to respin for a severe issue, the team may do so provided they report a failed smoke test status on [[WTP Smoke Test Results | 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.
 
*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 must be complete by roughly 9 AM EST Friday.
+
*In the event a re-build is required, then a new build will be complete by roughly 9 AM EST Friday.
  
 
== Friday ==
 
== Friday ==
Line 30: Line 35:
 
* Team development.
 
* 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 any build that week. In most cases, though, we will declare "with conditions" so potential consumers will know what to expect.  
+
* 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 any build 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.
  
 
[[Category:WTP Build Related| ]]
 
[[Category:WTP Build Related| ]]

Revision as of 11:42, 12 February 2009

Finding That Sweet WTP 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.

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 any build 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