Meeting Notes for 30 November 2007 Update Plan ReleaseProcess

Meeting Notes for 30 November 2007

Present: Liz, , Mihael, Eric, and Dale Ingram

This was a special meeting of just these four people to discuss how to migrate the LIGO e-Lab documentation from the old code base to the new "refactored" code base.

The most current version of the LIGO e-Lab documentation is on www13 and uses the "old" JSP code. We made plans for moving the content to www12 on port 9080. There was a lot of technical discussion about what is required for the move, mixed in with discussion about how we might alter the documentation system and database usage in the future. But we tried to keep that short and focus just on what we need to do to move the LIGO e-Lab documentation to the new code base, while keeping our options open for future improvments of the overall system.

Update Plan

Here is the plan:

1. Mihael will copy the LIGO e-Lab documentation from /elab/ligo on www13 to the server on www12, port 9080. He will make all the various changes (expected to be minor) required to get these files to process correctly using the new "refactored" code.
2. Liz will make the changes or additions to the database which are necessary for LIGO specific milestones, and if necessary for References, Glossary and Keywords. The References and Glossary will remain in VDS, while the Keywords will remain in the User database. In the future we may decide to put all 3 in one database system, but we can do that later and do it in parallel for all e-Labs (cosmic, LIGO, CMS, etc..)
3. Liz and Mihael will test the result for any obvious flaws, and correct them.
4. Dale will then test the final result, and he will report any problems, which Mihael and Liz will fix. Dale will sign-off on the correctness of the implementation. The version on www12:9080 will then become the test release of the LIGO e-Lab documentation.
5. Mihael will then copy the new, working test release back to www13 in place of what was there (the old stuff using the old code base), and he'll set this up to use the SVN repository. This will then be considered the development release. This step has to be done in conjunction with updating all existing e-Labs in development on www13 to the refactored code in case the old code requires different underlying infrastructure. The refactored and old code may not be able to co-exist. We may consider putting the old and new on different ports on 13.
6. All new features or other changes will generally be made to this development release, with the changes checked into SVN. When the newer version on www13 is considered stable and ready to release, it will be checked in to an SVN branch, and then this new branch will be checked out (rolled out) on www12:9080 as the new test release. This will generally be considered to be a release candidate, which means that if it passes further testing then it will to on to become the production release.
7. Whenever a test release has proven to be stable, with no "show stopper" bugs, then it will be rolled out on the production server as the production release. The production server for LIGO will be www18 once that has been configured and deployed.

ReleaseProcess

Here is a proposed outline for the release process, where development is done on the trunk and releases are branches. We should discuss this in our regular telecon, and if it's acceptable it should be added to the ReleaseProcess page. Here is the main idea:

All new features will be added to the development release and commited to SVN, on the trunk. When the development release is stable and seems to be ready for use then it will be committed to an SVN branch. That branch will be made the test release. If it passes all testing, it can then be put into production.

If minor problems are found in the test release they can be fixed in the branch and in the trunk.

If a major problem is found in the test release (a "show stopper", or just too much trouble to fix in both branch and trunk) then the branch is abandoned. The bug is fixed in the trunk and then a new branch is forked.

A major bug which affects production can be fixed either by rolling back to the previous release (that SVN branch), or by changing the code in place, with the changes commited to the SVN branch and applied to the trunk. This is more work, so we want to avoid ever having to make changes to the branch once it reaches production. Non-show-stopper bugs get fixed in development and then come out in the next release cycle of test release, then in the production release.

An alternative is to do development on a branch, with production in the trunk. Then merge changes from the branch to the trunk when they are ready. It's not clear to me how well that works for testing before release to production. I think that it could potentially make the production branch (the trunk) unstable, depending on when we do the merge.

For either scenario we need to consider the work required for regular development and rolling out a new release, and how we deal with adding new features, fixing minor bugs, or dealing with major bugs, including rolling back to an earlier release.

-- Main.EricMyers - 30 Nov 2007