Wiki

Case Status Kiln
Log In

Wiki

 
Integration process descriptio…
  • RSS Feed

Last modified on 24/09/2013 12:25 a.m. by User.

Tags:

Integration process description

 

Here is the pharo process. An enhancement
  • should be added to the bug tracker
  • announced to the mailing-list
  • asked for feedback
  • results should be added to the BT entry
 
A bug detected
 
  • discuss via the mailing-list
  • should be added to the bug tracker
  • fix are considered as enh (see point above)
When a fix is fixed it should be either post as cs to the BT entry or in the PharoInbox? as a Slice (a slice is an emtpy package that has as requirement other package composing the fix).
 
We have three project:
 
  • Pharo
  • PharoInbox?
  • PharoTreatedInbox?
A fix goes either from inbox to treatedInbox or to Pharo. If a fix does not work it is moved to the TreatedInbox?. If a fix works it is integrated as follow - it will be moved from the Inbox to the TreatedInbox? and integrated and published in the Pharo project
 
—————————————————————————————————————————
 
The following describes the integration process that is currently done by Stef, Marcus, and Esteban.
 
Now the integration works as 4 steps which can be steered by the following ScriptLoader releaseMenu
 
1.) Start up a recent and clean image
 
ScriptLoader new prepareNewUpdate
 
This step will
  • load the latest ScriptLoader? package from the Pharo repository. Indeed when we work on improving the ScriptLoader? it is useful to always have the last one.
  • check that the update.list (which contains the cs to load the packages) is in sync with the image current version.
  • snapshot the package version to detect dirty or changed but non dirty packages.
2.) Apply changes ScriptLoader new doneApplyingChanges This step will
 
  • create an update method with can trigger to load of the packages and some pre/post action
  • create a script method with describes all the package versions and it used by the update
  • save all the packages that are different (except some filtered packages)
 
into a local folder named package-to-be-tested.
 
3.) Verify changes
 
==> in a new image (in the current folder) execute:
ScriptLoader new verifyNewUpdate
 
This step will
 
  • load in any order (so may break) the package previously saved in the packages to be tested. It is an important step
4.) If there are problems go to 2.) to fix them, else: ScriptLoader new publishChanges
 
This step will
 
  • generate a new cs whose purpose is to load the given version of the scriptloader and trigger the correct update method.
  • add the name of the cs file to the end of the updates.list file local to the disc
  • copy all the package from the local directory to the Pharo
After the updates.list and the cs file should be manually uploaded to the ftp (see below)