CCS Release Strategy

Some ideas for discussion

• Short term
  • Please send a message to ccs mailing list whenever significant new code is put into subversion
    • Significant = Anything that would be likely to affect others
      • Anything except trivial bug fixes or code in "single-person" subsystems or experimental branches
  • Also update the release notes page and send a message to the ccs list when new packages are released
  • Ideally include references to JIRA's and/or confluence pages in the update message
    • Don't forget to include JIRA reference in your subversion commit message
• Medium term
  • Up to now "production" use of code has been restricted to "single-person" subsystems
    • Refrigerator, Single Filter Test: Owen and Francoise control what code is released to users
  • As we move further on with Vertical Slice Test we will have distributed users and developers
    • We will need to start making more formal releases
      • Right now "getting started " page says to checkout trunk, but should probably be modified to use specific release soon
  • Can we get subversion at lsstcorp.org to generate notifications using svnnotify or svnmailer ?
  • Can we make it easier to create branches to allow experimentation without affecting the trunk?
    • Max and I have started looking at ways to update subversion/maven organization to make this simpler
      • 
    • Also looking at whether moving to GIT would make this simpler
      • Will try to meet with KT Lim next week to gain from LSST Data Management group experience
  • Can we make use of standalone prototyping before merging code into main CCS repository
    • We could have developed standalone Maven project(s) to demo code distribution proposal
    • We could have developed standalone prototype of status/trending "crystalization" methodology
    • We are trying this with the command enhancement proposal
    • This will take more time, but for most items
      • We are not in a huge hurry
      • We will need to live with/support this code for many years
      • Getting more eyes/ideas on code at the prototype stage can only help
• Longer Term
  • Do we need to assign a "release manager" to assemble/test releases
  • Do we need to introduce more formal code review (git code pushes?)