Other operations (not part of the release management responsibility)

• RestartGangaJobRepositoryAtCERN
• GangaUsageMonitoringService

• HowToCVSTagAndBranch
• HowToPluginExternalGUIPanel

• HowToGangaRobot
• HowToGangaTestRobot

• MigrationProblemsSL4

• HowToTestingGridProxySetup (?)

• NewGangaRepository
• GangaFrameworkMigration
• JobRepositoryPerformanceTests
• GangaBox
• GangaDirac3
• GangaRobot
• GangaSandboxUtility
• GangaNG
• MigrationFramework 
• GangaMemoryFootprint
• GangaLiveOutputFromWorkerNodes
• GangaWindows

• Chep07Talk
• EgeeBudapest
• GangaOctopus

(see also outdated internal document: GangaTestingFramework)

Ganga Branches in SVN

Release 5.4

Release 5.5

Sync with trunk

Last merge: 13 Jan 2010 at revision 3061 (use this number to make a diff from HEAD below)

This is what has been done for core, resulting in revision 3247 (previous: 2872,2649)

export SVNURL=svn+ssh://svn.cern.ch/reps/ganga
svn co $SVNURL/branches/Ganga-XML-Refactoring-branch/ganga -d Ganga-XML-Refactoring-branch
cd Ganga-XML-Refactoring-branch/ganga/python/Ganga
svn merge --dry-run -r2649:HEAD svn+ssh://svn.cern.ch/reps/ganga/trunk/ganga/python/Ganga

#see diffs with this helper function

function bdf { svn diff $SVNURL/trunk/ganga/python/Ganga/$1 $SVNURL/branches/Ganga-XML-Refactoring-branch/ganga/python/Ganga/$1; }

XML Repository Testing

• Same ganga session
  • A number of ganga threads were launched to access the properties of running ganga job in a same ganga session. The status of job in the threads were matched with the status of the main job. The status of the main job and which come from different thread were same.
• Different ganga session
  • Run a ganga job session which submits 5000 job in a loop on a lxplus node (say node A) . On another lxplus node (say node B), start different ganga session. Following observations were found
  • On lxplus node B,
    • All the list of jobs were available in the xml repository.
    • The jobs submitted from node A was marked as 'submitted' during the entire life time of job submission script on node A. The job status was not updated during the life time of job submission script running on node A.
    • New jobs were allocated appropriate job id irrespective of many different open ganga sessions.
  • It is not possible to kill the job on other node which was submitted from different node due to repository lock error.
• Exceed of user's quota in XML repository folder
  • Proper warning and trace back message was transmitted to each open ganga session.

Beta testers (to be contacted when the first "usable" beta release is out):

• Kai Leffhalm leffhalm AT ifh.de
• Rob Lambert r.w.lambert AT ed.ac.uk
• Jibo He

Currently out-of-date (to be updated):

• GangaJobStateMachine (belongs to: GangaThreadsAndConcurrentJobAccess)
• GangaRepositorySynchronizationAndUpdateIssues (belongs to: GangaThreadsAndConcurrentJobAccess)
• GangaRemoteWorkspace (belongs to: GangaJobWorkspaceInterface)

-- JakubMoscicki - 15-Dec-2010