Meeting Notes for 12 December 2007

Present: Eric, Mihael, Liz
Absent: Bob, Mike W. Randy, Tom L. , Dan K., K. Whelan Joao, and Tom J. (Tom J., Kris and Bob at QuarkNet meeing in California.)

New Data Server

The server is still not up; Mihael will send email to try to understand what the problem is.

Machines for schools to test LIGO e-Lab

We decided that for now the schools should use http://www13.i2u2.org/elab/ligo, since this is currently the most stable version of the LIGO e-Lab. Dale will make it clear to them that this is a test version and that eventually we will have this on the production site, and that then they will be accessing it with http;//www.i2u2.org/elab/ligo/. Currently we do not know how to move work from the www13 databases to the production, and we are not sure we would want to anyway. We are hoping the teachers can give us some feedback. To make this work for the schools that are having problems handling port 8080, we will need to fix for the login. (see next item)

Problem with login on www13 related to the firewall in the school issue.

The reverse proxy works except for the call to login from the home and teacher pages, where we use a call with the machine and port number 8080. The material served on the secure port for www13 does not work for this. We will change the home and teacher pages for LIGO on www13 to use relative links, so for now the research groups should be able to log in and not have issues with port 8080 blocking. We need Dale to confirm this with the school that was having problems.

Release strategy using SVN (or CVS), including:

We discussed a development/test/release strategy which Eric and Mihael had been discussing previously. The general ideas are:

• Development is on the trunk, and then copy the trunk to a "branch" for a release.
• Three levels (production+testing+development) - This is similar to our current rollout procedure, except that we are going have a longer, more stringent test cycle, hopefully involving knowledgable users outside of our small group ("beta testers").
• Need to discuss how to deal with normal releases versus fixing bugs or rollbacks.
• Use branches (but not tags, since SVN is all branches, no tags)

Machine www13 will be a "development" machine. For Mihael, his laptop is his development environment. For Eric the spy-hill site is a development machine. We will merge additions and changes into SVN from the development machines, into the trunk

Machine www12 will be the testing machine; we will rollout to www12 from a new branch in SVN, and after 1-2 weeks of intensive testing we will then rollout from the same branch to the production machine, assuming no major problems are found. Minor problems can be fixed in the branch (and in the trunk).

The hardware which was data0 will become www18 and be the main production machine, which will send analysis jobs to the machines that are currently in the load-balancing pool.

Machine www12 will use a copy of the production database. When users move from "testing" on www12 to production they lose their work.
Question: how often do we copy the production database for use in testing?

Deployment will be for all the e-Labs at once, not just LIGO or just cosmic.

Each new release (making of a new branch) will be up to small number of people. We don't expect this to be something an educator developer would do. Their new contributions would always be in the development trunk, and then go into the next branch when released.
Question: what about material which is in a database, like glossary and references? This strategy is for code.

Requests to make a release, and related discusion, can be done through the existing email list.

We will document rollouts in CI Wiki.

How we would deal with major or minor bugs:

• Major bug -- fix in trunk; rollback to previously known good production release (branch)
• Major bug caused by a new release -- abandon branch and roll back to the previous branch
• Medium bug -- typos -- you could change in both trunk and branch.
• Minor bugs -- make change in trunk so it will show up in the next release.

When would we rollout a new branch?

• When there is a feature everyone needs soon, or a needed bug fix.
• When it is time to test some new features that people want, but are not clamoring for.

Action Item: Eric will write up the strategy as a wiki page.

We will archive the current documentation on rollouts, and then link to the new wiki page.

-- Main.LizQuigg - 14 Dec 2007
-- Main.EricMyers - 18 Dec 2007