[Systers-dev] Summer of code changes pushed to production

[Robin Jeffries]

We pushed all the changes that were ready for production this evening (all
the stuff that we've been testing the last couple of weeks).  I thought I
would update folks on how it went (and record what we learned for
posterity).

1.  We had a few bzr (the source control system) glitches.
    -  When new files are added to a directory, the entire directory gets
rewritten, with the existing version moved aside.  This might be a
configuration issue at the top level or might be that people aren't adding
new files correctly.  Jen is looking into this and will add to this thread
what she learns.
   - there were 3 (relatively trivial) cases where there were conflicts.
 They all look like someone forgot to pull down the latest version from
launchpad (and resolve the conflicts with her version) before committing her
branch.  We need to remember to pull down code before we commit. (a more
robust system would force this behavior, but bzr is based on the unix
principle that everything should be permitted, as you never know when
someone will have a good reason for doing that thing :-).  Luckily, in each
case it was obvious how to resolve the conflict.

2.  We found 3 bugs in the code.  We were able to do an emergency patch for
1 of them, but the other two will need fixes asap
    - there was an error condition that crashed while reporting the error.
 It looks like some changes where made elsewhere in the code and not
everything was cleaned up (the error message references an undefined
variable, which causes the crash; I suspect that variable used to be
defined, but when it went away, it got left behind in the error message)
   - while we created a GUI for adding essays and full names when a list is
created, we totally forgot that we will need to modify those variables for
existing lists.  I take responsibility for this -- I was helping with the
original GUI, but didn't think about editing being done in a different
place.  Oops.
   - when email (usually spam) is sent to a list that doesn't exist, the ORM
(database manager) code crashes rather than returning a message that the
list doesn't exist.  Since we get a LOT of spam sent to these addresses,
this is a problem.  But I can easily see how it would be easy to miss
testing for what happens when a list does not exist.  We are all learning
how to think of things that might go wrong.  We need to add to the testing
template a test that involves sending mail to a non-existent list.

All in all, given how much we are learning as we go, this went quite well.

Robin