A View on Current Cactus Management and Possible Futures Outline

Project management A view on current Cactus management and possible futures Outline

• Current status of the Cactus project management (as far as I understand it)

• What is available at CERN/the world?

• How can we do it better? Current Cactus project

• One SVN repository for all sub projects (7.9 GB in size)

• nightly builds for testing

• one ticket system (trac)

• Drawbacks:

• history of commits includes all packages

• all projects have to follow the same commit procedure

• other projects can break (all of) cactus

• takes long time to checkout

• all draw backs of SVN (sooo last century) Available tools

• In the recent years CERN started to provide more and more useful tools for developers:

• JIRA for issue tracking

• GitLab: git + web frontend for code review + CERN authentication

• Twiki for documentation

• Jenkins: continuous integration

• More at the developers@CERN conference (recordings available)

• https://indico.cern.ch/event/404359/contribution/3/attachments/1160473/1671621/2015-09-29_- _DevelopersCERN_Forum_-_Continuous_Integration_and_Code_Review.pdf

• All accessible from https://cernforge.cern.ch/ Gitlab

• Like Github but CERN only (can have private repositories)

• encourages code review workﬂow

• has the beneﬁts of git (>> SVN)

• has submodules (more later)

• It should be easy to move Cactus from CERN SVN to Gitlab if required (https://www.atlassian.com/git/tutorials/migrating-overview/) Merge requestsPull requests

29-Sep-2015 1st Developers@CERN Forum 6 Jira

• A quick overview: https://www.youtube.com/watch? t=49&v=xrCJv0fTyR8

• Bug tracking and project planning tool

• Compare to track (http://project-management.zone/system/jira,trac)

• time tracking, smileys

• Personally I am not very familiar with it, but it seems Jira >> track So how can we make best use of these tools? The goal

• Do not change the cactus build structure (change as little as possible in one step)

• Give each project full reign about their management and release cycle

• Make sure that the projects can be synchronised to produce a cactus version The submodule route • move all projects in cactuscore, cactusprojects & cactusupgrades to separate repositories

• keep the reference to them (tag/branch/commit) via git submodule

• Example: Submodules • Submodules will change the build script slightly:

• git clone … becomes git clone && git submodule init && git submodule init

• new subproject versions can be included via pull request (like any other changes since they count as commits! More on the topic • SVN -> Git, 1 repo -> N repos (1 for cactus, M for subprojects)

• more control via pull requests (& code review & automated testing via jenkins)

• nobody commits directly to the main repo

• The biggest piece of work for this transition is mapping user names to emails (git stores authors as username , SVN user name only)

• and of course an idea what you would like to transfer (tags/ branches/trunk)