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 workflow • has the benefits 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 <email>, SVN user name only) • and of course an idea what you would like to transfer (tags/ branches/trunk).