Re: [GeneX-dev] Release management perspective...

[Todd P. <tf...@nc...>]

Excellent suggestions, Michael! We REALLY need a SQA person full-time to =
support us on this. Peer reviews are another effective way to help =
minimize the evils of SW change. I am an advocate of the SEI CMM =
(sei.cmu.edu).
  ----- Original Message -----=20
  From: Michael Pear=20
  To: gen...@li...=20
  Sent: Saturday, January 27, 2001 8:02 AM
  Subject: [GeneX-dev] Release management perspective...


  Hi GeneX Developers,

  I'd like to offer some ideas based on my experience managing
  software releases, albeit in a commercial environment, not open =
source. The
  comments aren't meant to be directed at any of you specifically...I've =
been very
  impressed with the responsiveness of the team to issues I've =
encountered, and
  we could not be where we are today at our site without your efforts!

  The fundamental precept of a release is that change is your enemy. Now =
is not
  the time to catch up on those things that you really wanted to get =
done
  for the release! One analogy that I like is from "The Dyamics of =
Software
  Development" by Jim McCarthy:

  "Shipping a product is like watching a large-sized serving of =
quivering Jell-O. Gradually, the Jell-O slows its vibrations. But then =
you fix a bunch of bugs, and it starts quivering frenetically again. =
Then slowly, ever so slowly, the quivering subsides. You wait, focused =
and primed, for the instant the Jell-O stops shaking. Then....you ship =
it!"

  (I highly recommend this book as a whole, even if you suffer an =
adverse physical reaction if you see "Microsoft Press" on the cover of a =
book:-)

  The second precept is that you must make changes to get the release =
out. But these must be made only with the application of judgment that =
the change is aabsolutely necessary to make. I usually apply three =
questions:

  1) What is the impact of the bug or issue?
  2) What is the effort involved?
  3) What is the risk to the release of introducing the change?

  For example, often times we automatically fix a crash, even though it
  only affects 1% of users in .5% of situations and requires a =
significant change in a central piece of code that affects 100's of code =
paths, but ignore a nuisance bug that 100% of users experience, vitally =
affects their perception of your software, and only requires one line of =
code in a non-central location. Exaggerated, I'm sure, but you get the =
point.

  I suggest a few things to consider:

  1) Create a release checklist of bug fixes and any other changes you =
decide must be in the release for the server + curation tool together. =
Someone needs to act as the release manager, resisting change and =
keeping the checklist..and you need to allow that person to make a "no" =
decision regarding a proposed change!

  2) If you haven't already, create a CVS branch for the release and =
only
  make changes in it according to the release. When the release is done,
  then you can tag the branch as the release, and merge in the =
development changes. Take your urges for more dramatic change out in the =
development branch

  3) Do regular "builds" of the system rather than patch. Changes have a =
way of getting into test systems through patches that don't end up in =
the source code tree!
  In the end, if you can't build it from the CVS tree, then you can't =
reproduce the release.

  Releases have a way of dragging on...I know from personal experience. =
Hope some of these tips help.

  Regards,

  Michael Pear